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Performance Data Errors in Air Carrier Operations: 
Causes and Countermeasures 

Benjamin A. Berman 1 , R. Key Dismukes 2 , and Kimberly K. Jobe 3 


Executive Summary 

Several airline accidents have occurred in recent years as the result of erroneous weight or 
performance data used to calculate V-speeds, flap/trim settings, required runway lengths, and/or 
required climb gradients. Only one of these accidents incurred fatalities, but the potential for future 
accidents with large numbers of fatalities prompted the French and the Australian aviation 
authorities to conduct reviews of the risks. In this report we consider and extend four recent studies 
of performance data error 4 , report our own study of ASRS-reported incidents, and provide a broad 
set of countermeasures that can reduce vulnerability to accidents caused by performance data errors. 

Performance data are generated through a lengthy process involving several employee groups and 
computer and/or paper-based systems. Although much of the airline industry’s concern has focused 
on errors that pilots make in entering flight managment system (FMS) data, we determined that 
errors occur at every stage of the process and that errors by ground personnel are probably at least 
as frequent and certainly as consequential as errors by pilots. Although relatively few major 
accidents have yet been caused by performance data errors, our study suggests that more accidents 
are likely to occur unless existing measures to prevent and catch these errors are improved and new 
measures developed. 

Six kinds of error are of greatest concern: I) ground personnel errors in obtaining, calculating, and 
entering weight data; 2) FMS data entry errors by flight crew; 3) errors made in checking against 
limitations; 4) flap and trim configuration errors, 5) fuel weight errors by either ramp personnel or 
pilots; and 6) errors by pilots using cockpit laptop performance computers and electronic flight bags 
(EFBs). Cutting across several of these six categories were errors made either by ground personnel 
or by pilots while manually entering data. 

Most of the errors we examined could in principle have been trapped by effective use of existing 
procedures or technology; however, the fact that they were not trapped anywhere in the chain of 
developing and applying the data indicates a need for better countermeasures. Existing procedures 
are often inadequately designed to mesh with the ways humans process information and their 
associated vulnerability to error— and procedures often fail to take into account the ways in which 
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information flows in actual flight operations and the time pressures experienced by both pilots and 
ground personnel. 

Because data entry errors are so prevalent, we suggest that airlines employ automated systems 
(feasible with current technology) that eliminate the need for manual data entry wherever possible 
in the process. For instance, this could include implementing automation to enter data by scanning 
passenger and cargo documents and eliminating the need to re-enter data by providing direct 
communication that allows sharing of data between the various computer systems. 

Without effective countermeasures, errors will inevitably creep into the data process because of 
human cognitive vulnerabilities and operational exigencies. Many error-trapping procedures fail 
because the various data checks all use the same source of data and thus produce the same 
erroneous output. To make error trapping procedures as effective and reliable as possible, they 
should be designed to validate the performance data process by using independent sources of 
information, data entries, calculation processes, and data transmission. To preserve the 
independence and maximize the reliability of error-trapping procedures, airlines should design and 
implement these procedures in enough detail to explicitly guide the personnel performing them; for 
example, specifying the forms, displays, and control indicators to be looked at for verification. 
Airlines can further improve reliability by training personnel in methods to control rushing, to 
enhance deliberate execution of procedural steps, and to encourage deliberate review of status. 

An autonomous onboard weight-and-balance sensing system— as an independent source of 
information— can serve as an effective cross-check for the weight and balance values derived from 
the performance data process. With the capability to update its calculations in real time, this 
technological intervention can effectively prevent errors caused by last minute load changes. 

Even with weight and balance verified by onboard sensing, subsequent calculations and manual 
data entries, such as performance speed parameters, flap settings, and trim settings, can introduce 
additional errors downstream in the process. These can be trapped by additional verification 
procedures, such as well-designed cross checks conducted by pilots and by technological systems, 
such as automatically uplinking calculated performance settings into the FMS and programming the 
FMS to cross-check the uplinked values with its internal calculations. Regardless what approach to 
verification is taken, weight and balance information— as well as performance parameters derived 
from this information— should be compared between independent sources. 

FMS interface design can be improved to prevent some types of data entry errors. For example, for 
those designs not already modified, it should be possible to modify FMS software so either zero fuel 
weight (ZFW) or gross takeoff weight (GTOW)— but not both weights— can be input by the pilots. 

Throughout performance data processes it is critically important for both ground personnel and 
pilots to resolve discrepancies identified during cross-checks of performance data. Airlines should 
inculcate this practice into operational culture and line norms by proceduralizing, training, and 
encouraging it. Discrepancy resolution procedures should establish thresholds for specific 
discrepancies, such as fuel weight, defining those that are acceptable and those requiring resolution. 

One cross-check that can be readily incorporated in airline procedures is a pre-departure 
comparison between the preliminary (flight-planned) and the final weight/balance data. This 
procedure is valuable because the preliminary data are based on seats previously booked by 
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passengers and cargo that the airline has planned to be loaded, while the final data are, in most 
cases, developed independently. However, the effectiveness of this procedure depends on 
discrepancies between these values being resolved before departure by independent verification 
(such as an autonomous onboard weight/balance sensor) or by back-tracking through the entries and 
calculations of the individual load elements and correcting these previous steps in the performance 
data process. 

Some of the mitigations proposed in our study would require airlines to develop new procedures, to 
modify existing procedures to provide enhanced independence, or to specify existing procedures in 
greater detail so personnel can be properly trained and then perform the procedures on the line 
effectively. Other mitigations would require enhanced technology, most of it already existing and in 
some cases already in use on some aircraft. All of these mitigations are achievable but some of 
them would require airlines to make significant investments (especially those operating aircraft 
with older FMS and databus communications systems). Cost-benefit analysis is beyond the scope of 
this study but the risks and potential consequences of performance data errors are substantial and 
the safety benefits of mitigating them are clear. 

The need for new measures should be considered in the light of changes in the national air transport 
system planned under the Federal Aviation Administration (FAA) NextGen program. Some aspects 
of NextGen, such as shifting responsibilities for control of flight path between air traffic control 
(ATC) and the flight deck, will probably not affect the kinds of errors discussed in this report; 
however, other aspects may increase vulnerability to performance-data errors if countermeasures 
are not applied. In particular, under NextGen the volume of air traffic is expected to increase 
substantially. Although some of this increased volume may be accommodated by reliever airports 
(under the multiplexing concept) existing major airports will handle more traffic, thus will launch 
more aircraft per hour. With more operations, more opportunities for performance-data errors will 
occur and personnel may have less time to detect and correct the errors; hence improved 
countermeasures will become more urgent. These countermeasures will also be crucial for reliever 
airports, which may have less experience with high volume operations. 

Under NextGen it is also envisioned that datacom will be used to transfer most information among 
the flight deck, ATC, and airline operations centers (AOCs). To the extent that these data 
communications are implemented in the current technology, which is largely similar to text 
messaging, typing and reading so many datacom text messages will greatly increase opportunities 
for errors, including load and performance data errors. Also, in this form of data communications, 
operators are prone to accept such text messages without critically checking values so the need for 
error prevention and trapping will increase. On the other hand, if the necessary data 
communications are highly integrated so the informational output of one sub-system, such as the 
airline’s performance data system, flows autonomously to become the input for other sub-systems, 
such as NextGen enroute and approach metering and sequencing, then NextGen technology has the 
potential to serve as a mitigation for data entry error. 
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1. Introduction 

On October 14, 2004, a Boeing 747 freighter operated by MK Airlines crashed while departing 
Halifax, Canada. On its previous flight the aircraft had departed from Hartford, Connecticut, at a 
takeoff weight (TOW) of 240,000 kilograms. The aircraft was then loaded at Halifax with 
additional fuel and cargo and the planned TOW for the departure from Halifax was 353,000 
kilograms. The crew used a laptop-based program to calculate the performance data for the 
departure, including values for takeoff reference speeds, also known as V-speeds— decision speed 
for engine failure (VI), rotation speed (Vr), safety speed for engine failure (V2)— as well as engine 
thrust, flap setting, and pitch trim. The laptop program used inputs by the flight crew for aircraft 
weight, runway, and weather to derive these performance numbers. The crew entered the Halifax 
runway and weather into the laptop computer but apparently the weights from the previous takeoff 
at Hartford remained active in the laptop program. Consequently, the laptop-calculated V-speeds, 
thrust values, and trim settings were for a much lighter weight than actual. The crew then 
apparently omitted company procedures for independent data verification and gross error checks so 
the error was not caught. 

Using the incorrect performance data, the crew attempted to rotate the aircraft to its takeoff attitude 
at a speed that was too slow for its actual weight. Such a takeoff rotation with insufficient airspeed 
can result in a transport aircraft such as the 747 entering a high-drag condition that can delay or 
prevent its climb away from the runway. Also, to mitigate engine wear, many takeoffs are 
conducted using reduced or derated thrust settings which are based on the power needed to lift the 
planned weight off the runway and through the required climb transitions. In the case of this 
attempted departure from Halifax, the calculation using the wrong weight resulted in lower-than- 
required thrust, compounding the effects of the early takeoff rotation and further delaying liftoff. 
Consequently , unable to climb, the 747 crashed just off the end of the runway, killing all seven 
aboard (Transportation Safety Board of Canada, 2006). 

On March 20, 2009, an Airbus 340 operated by Emirates Airlines received substantial damage 
during an attempted takeoff from Melbourne, Australia, following a 100,000 kilogram error in the 
crew’s entries to the laptop-based computer program. In this case, a pilot entered 262 tons instead 
of 362 tons in the TOW field of the laptop input screen. The airline’s standard verification 
procedures did not catch the error. 

During the takeoff roll, the aircraft accelerated very slowly. Just before the end of the runway, the 
flying pilot rotated aggressively, striking the tail on the pavement. The aircraft continued beyond 
the runway surface and rolled through grass, clipped an airport structure, then slowly climbed away. 
There were no injuries, but this accident was considered to be a close escape from catastrophe. 

Similar events occur, some narrowly escaping becoming accidents. One flight crew reported to the 
NASA Aviation Safety Reporting System (ASRS): 5 

“The operations agent handed me the load sheet and 1 began to make the appropriate 

entries in the flight management computer and laptop [performance computer] . . . we 

proceeded to push, start, taxi, and take off uneventfully. 

Once in the air, we received a radio call from operations telling us to revise our takeoff 

weight... the correct weight was actually 19,000 pounds heavier. We then realized... the 


5 ASRS Reports 664643/664644. 
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operations agent had entered 33 passengers into the computer versus the 133 passengers 
that we actually had. 

The plane took off fine, although the captain said it felt a little mushy on liftoff... I can't 
believe that I missed this large error. I quickly scanned the form. . .1 think part of the 
problem is that with the new computer-generated form, I have stopped looking for math 
errors like 1 did with [the] old form. This can create a false sense of security... on this 
flight, all three of us failed to catch a simple error and the check and balance we rely on 
broke down.” 

Many opportunities for error occur when aircraft load data (e.g., weights of fuel, cargo, and 
baggage) are processed to derive the aircraft performance information (e.g., required runway 
lengths, climb gradients over obstacles, and margins above aerodynamic stall) and the associated 
values for V-speeds, trim settings, and flap settings. Data processing is involved when gate and 
ramp personnel load passengers, baggage, and cargo; airline central offices and station facilities 
plan and control load; and pilots enter data into laptops and FMSs and calculate flap, trim, and 
cruise altitude values. Errors in these processes have resulted in fatal accidents (Halifax B-747), 
structural-damage accidents (Melbourne A-340), numerous incidents involving less serious 
damage, and a large number of reports by pilots to the ASRS. No passenger-carrying aircraft has 
been lost recently because of such errors, indicating that existing safety procedures and systems are 
at least partially controlling the risk, but the events that have occurred suggest the potential still 
exists for accidents with many lives lost. 

The purpose of this study is to identify the sources and kinds of errors in processing performance 
data in air carrier operations, including the failure of the involved personnel and systems to reliably 
trap and correct errors before producing adverse outcomes. Initially the focus of our research was 
directed toward errors made by pilots while entering weight data into FMS control display units 
(CDU/MCDU) in the cockpit. However, review of the literature and accident/incident data 
suggested that the sources of error and error-trapping failure are not limited to the FMS data entry 
actions of the flight crew but also frequently involve errors in data generation and performance 
calculations by airline operation center, central load planning office, or at the local station 
operations office personnel. 

Years ago, pilots made their own performance calculations based on the counts and weights of 
passengers, cargo, baggage, and fuel that were relayed to them by ground personnel. They added up 
the weights to derive takeoff and landing weights, consulted tables to calculate the aircraft’s 
balance (center of gravity position), factored in the winds, temperature, and runway information, 
verified the calculated weight/balance against the aircraft’s limitations with the help of tables or 
placards on the instrument panel, and obtained reference speeds, trim settings, and thrust settings 
from additional tables and graphs. They posted the V-speeds and thrust settings on handwritten data 
cards and perched them in view on the panel for ready reference and they also set moveable plastic 
“bugs” at the rim of the airspeed indicators. 

These processes are still used in some operations, but today these same functions may be performed 
by pilots using laptop computers that accept entries of the individual components of aircraft weight 
(such as counts of boarded passengers and the weights of cargo containers loaded in underbelly 
bins) together with other entries about the runway and weather conditions to generate the V-speeds, 
trim settings, and thrust settings— verifying compliance with all of the aircraft’s performance 
limitations along the way. Or these same functions may be performed by ground personnel in a 
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central load planning office or at the local station operations office with the performance speeds and 
other data relayed to a cockpit printer or even uplinked directly into the FMS computer in the 
aircraft. This re-distribution of tasks among various flight, ground, and back-office personnel has 
simplified the tasks for some personnel but requires coordination and cross-checking among all the 
players to prevent and catch errors. Unfortunately, the overall system has become less transparent 
to users— making coordination and cross-checking more difficult. 

With these trends in mind, we broadened the focus of the study to include performance data errors 
and error-trapping by all personnel and departments involved in the process of generating and using 
load and performance data. The Halifax and Melbourne accidents illustrate two possible outcomes 
of performance data errors but other adverse consequences are also possible. In this report we 
discuss examples of a broad range of potential consequences: 

• Premature rotation leading to tailstrike or inability to achieve liftoff 

• Inability to rotate due to mistrim 

• Inadequate thrust for runway length 

• Inadequate climb performance over obstacles 

• Inadequate performance in the event of engine-failure contingencies (both rejected takeoff 
and continued takeoff after engine failure) 

• Excessive fuel consumption or stall during cruise 

• Stall or hard touchdown during approach and landing 

• Instability during all phases of flight caused by excessive aft center of gravity (CG) 

• Structural damage (observable or hidden) from overloading 

We start by analyzing the sources and types of performance data errors, drawing upon an ASRS 
search, results from previous studies, and accident/incident investigations. We then examine the 
adequacy of airlines’ performance data processes to trap these errors, using both currently 
employed procedures and systems and those that are potentially available in the future. We 
conclude by proposing measures to improve airline performance data processes by (1) reducing the 
occurrence of these errors to the extent that is realistically possible and (2) increasing the 
effectiveness and reliability of error trapping so those errors that do occur will be caught and 
corrected before flights are exposed to risk. We focus especially on errors with potential to cause 
major adverse consequences. 

The need for new measures should be considered in the light of changes in the national air transport 
system planned under the FAA’s NextGen program. Some aspects of NextGen, such as shifting 
responsibilities for control of flight path between ATC and the flight deck, will probably not affect 
the kinds of errors discussed in this report; however, other aspects may increase vulnerability to 
performance-data errors if countermeasures are not applied. In particular, under NextGen the 
volume of air traffic is expected to increase substantially. Although some of this increased volume 
may be accommodated by reliever airports (under the multiplexing concept), existing major airports 
will handle more traffic and thus will launch more aircraft per hour. With more operations, more 
opportunities for performance-data errors will occur, and personnel may have less time to detect 
and correct the errors; hence improved countermeasures will become more urgent. These 
countermeasures will also be crucial for reliever airports which may have less experience with high 
volume operations. 
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Under NextGen it is also envisioned that datacom will be used to transfer most information among 
the flight deck, ATC, and AOCs. To the extent that these data communications are implemented in 
the current technology, which is largely similar to text messaging, typing, and reading, so many 
datacom text messages will greatly increase opportunities for errors, including load and 
performance data errors. Also, in this form of data communications operators are prone to accept 
such text messages without critically checking values so the need for error prevention and trapping 
will increase. On the other hand, if the necessary data communications are highly integrated so the 
informational output of one sub-system, such as the airline’s performance data system, flows 
autonomously to become the input for other sub-systems, such as NextGen enroute and approach 
metering and sequencing, then NextGen technology has the potential to serve as a mitigation for 
data entry error. However, when data are transferred autonomously, operators are prone to accept 
such inputs without critically checking values so the challenge and need for error prevention and 
trapping will increase under NextGen technology. 

2. Literature Review and Analysis 

In this section we review existing literature about performance data errors, focusing on problem 
definition, error causes and outcomes, and ideas about risk mitigation. In addition to several safety 
studies, we examined numerous investigative reports of accidents and incidents involving 
performance data errors. Rather than repeating the description of the events during these accidents 
and incidents, though, we only summarize selected aspects that we drew upon in our own study. 

2.1 Defining the Problem 

Describing a Boeing study, Santoni and Terhune (2000) noted that airlines have experienced 
tailstrikes, high speed rejected takeoffs, and other adverse outcomes when pilots used V-speeds that 
were lower than required by the actual weight of the aircraft and operating conditions. The pilots’ 
use of these low V-speeds, in turn, were “caused by a variety of human errors that typically resulted 
from using an erroneously low value for gross weight or an incorrect flap reference setting when 
determining takeoff speeds” (p. 15). 

Santoni and Terhune listed examples of errors occurring throughout the performance data process 
that could result in these consequences. They evaluated the major Boeing aircraft types with respect 
to susceptibility to a significant consequence. For example, long-range aircraft with high fuel 
capacity (e.g., 747 and 777) could have a rotation speed error of as much as 36 knots— a very large 
error— if the ZFW value were substituted for the GTOW value or if weight were entered in 
kilograms instead of pounds. Also, the high-lift wing of the 757 was susceptible to a rotation speed 
error of as much as 25 knots if the wrong flap setting were applied. 

2.2 Errors and Outcomes 

Four recent studies— largely case-based— have identified problem areas in performance data errors 
and suggested mitigations. 
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2.2.1 Laboratory of Applied Anthropology Case Review, Observational, and 
Survey Study 

A research group comprising representatives of the French civil aviation authority (DGAC), 
accident investigation agency (BEA), and operational and human factors experts (Laboratory of 
Applied Anthropology, 2008) reviewed 12 performance data incidents worldwide from 1990 
through 2006 that were investigated by accident investigation agencies. The group also observed 
flight operations at two air carriers and surveyed pilots from these air carriers about their own 
experiences with performance data errors. The incident investigations revealed several types of 
performance data errors, including: 1) one instance of mistaken use of data from the previous flight 
(similar to the Halifax 747 accident); 2) two instances of substitutions of ZFW values for GTOW 
values during data entries into laptop performance data computers (similar to the Melbourne A-340 
accident); and 3) additional erroneous data entries by pilots using laptop computers or Aircraft 
Communications Addressing and Reporting System (ACARS) data communications from the flight 
deck to a central load computer, resulting in transfer of incorrect information into the FMS. Only 
one error involved an incorrect keyboard entry into an FMS; this was an incorrect VI speed that a 
first officer entered during taxi and that was not cross-checked by the captain. All of the other 
errors in this study occurred either earlier in the sequence— so the pilots were provided with 
incorrect data (or miscalculated it themselves)— or later in the sequence so the pilots used valid data 
incorrectly (e.g., setting the trim wrong). 

This study determined that “Half the [30] crews who responded to the survey... had experienced 
errors in parameters or configuration at takeoff’ (p. 67). Further, the study called attention to the 
roles of time pressure and late changes to performance parameters in these errors: 

“The real-time availability of the final weight information a short time before 
departure obliges the crew to perform a large number of tasks, inputs and parameter 
displays under strong time pressure. ..Time pressure and task interruptions are 
frequently cited in surveys as common factors contributing to errors. The 
observations showed that the crews’ workload increases as the departure time 
approaches and that the normal operation actions of the captain were all the more 
disrupted...” (p. 67-68). 

Regarding pilots’ ability to catch performance data errors by recognizing out-of-bounds values, 8 of 
the 30 surveyed pilots reported using this informal, non-procedural method. The study noted, 
however, that today’s airline pilot no longer possesses a working knowledge of the orders of 
magnitude of the aircraft’s performance parameters, making it difficult to recognize even a gross 
data error. The study suggested that training could improve pilot performance and further 
recommended that pilots be provided with a placard or display incorporating key values for a range 
of typical conditions. Still, this means of trapping performance data errors was evaluated as being 
“insufficient” (p. 43-44). 

2.2.2 Australian Transport Safety Bureau Case Review of Flight Crew Errors 

The Australian Transport Safety Bureau (ATSB) examined 20 international and 1 1 Australian 
takeoff accidents and incidents related to performance data errors over a twenty-year period 
(Hughes & Godley, 201 1). This study was limited to errors made by flight crews; a companion 
study, discussed below, examined errors made by ground personnel. 
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In the 20 international accidents/incidents which were evaluated in the greatest detail, the ATSB 
found that: 

• Sixteen involved incorrect entry or calculation of weight parameters while another three 
involved incorrect entry or calculation of V-speeds. 

• Eleven involved the wrong datum being used, such as using ZFW instead of GTOW, using 
the GTOW from the previous flight, or entering the wrong fuel value. Another four events 
involved having the correct figure but entering it incorrectly. 

• Performance data documents (including load manifests and tabular or graphical references 
for weights and speeds) and laptop performance computers were the equipment most 
commonly involved in the errors. There were three instances of pilots substituting ZFW 
for GTOW while using a laptop, similar to the Melbourne A-340 accident. 

• Tailstrikes, collisions with terrain/obstacles, and reduced takeoff performance were the 
primary consequences of these errors; however, we note that the ATSB probably selected 
these accidents/incidents because of their potential seriousness and thus a wider range of 
consequences may exist. 

This study highlighted the role of changing conditions in several of the errors that occurred in the 
20 events. Pilots were sometimes assigned runways different from the runways for which 
performance calculations were originally made; pilots sometimes received a revised load sheet with 
a changed TOW; and on occasion the normal method of obtaining performance data from 
dispatch/central load planning was not working so alternative means had to be used. 

Failures of monitoring and checking were the most common errors; “[t]hese involved crew actions 
associated with verification or cross-checking of takeoff data computations not being completed by 
the crew” (p. 64). The most common situational contributing factor involved pilots who had 
recently transferred from another aircraft type for which the erroneous weights/speeds would have 
been appropriate, thus limiting the pilot’s ability to identify the erroneous values as being out of 
normal bounds. 

The ATSB examined failures in what it termed “risk controls” similar to what we call verification 
and error-trapping procedures and systems. Among these, the most common failures were related to 
automation systems and the crew procedures for using them. Examples of automation-related 
factors were: 

• “The system accepted mismatched values without challenge.” 

• “TOW was the required input value for the aircraft communications addressing and 
reporting system [but] the ZFW was the required input value for the [FMS].” 

• “The system was configured in a way that prevented the crew from conducting a gross 
error check” (p. 68). 

• There was “no inbuilt function to alert the user that the values entered were unrealistically 
low or mismatched (compared with the values already calculated by the system).” 

• “The system reverted to the information entered for the previous flight” (p. 72). 


9 


Examples of procedural factors in the errors were: 

• “Procedures did not specify who was responsible for calculating takeoff data” (p. 68). 

• “No procedures in place to compare or independently verify the takeoff performance 
parameter values with other sources, such as comparing the data entered into the laptop 
computer with that automatically calculated by the flight management computer.” 

• “No requirement for the calculations made by one crewmember to be cross-checked by 
another crewmember.” 

• “No requirement to cross-check all of the takeoff performance parameters, for example, a 
cross-check of the V-speeds was required but not the aircraft’s TOW.” 

• "The roles and responsibilities of crewmembers, including the third or relief pilot, were not 
clearly defined with respect to calculating and verifying takeoff performance calculations.” 

• “No procedure in place for calculating takeoff performance data when the primary system 
used to conduct this task was unavailable” (p. 71). 

2.2.3 Australian Transport Safety Bureau Case Review of Ground Personnel Errors 

The ATSB evaluated aircraft loading errors that occurred in Australia and were reported to the 
Bureau during a 7-year period ending in 2010 (ATSB, 2010). While many of the events were 
related to incorrect securing of cargo (an occurrence unrelated to our focus on performance data 
errors), other events fell within the scope of our study. These included: 

• Unlisted cargo/baggage being loaded aboard (or not unloaded from a previous flight); 
listed cargo not being loaded (making the aircraft lighter than calculated, but potentially 
out of balance or trim). 

• Incorrect fuel loads. 

• Cargo/baggage being loaded in the wrong location (not adversely affecting weight 
calculations but with possible serious consequences to CG and trim calculations). 

• Loadsheet errors such as listing the wrong number of passengers. 

• Receipt of a new loadsheet after takeoff. 

• Aircraft-specific parameters (such as basic operating weight/CG) incorrectly encoded in 
computer records and used for calculations. 

2.2.4 Henriqson, Winsen, Saurin, and Dekker (2010) Case Review 

Henriqson and colleagues summarized the outcomes of performance data errors based on a review 
of 22 occurrences since 1991 (Henriqson, Winsen, Saurin & Dekker, 2010). The authors cautioned, 
“Rather than an exhaustive list of this type of event, the information for these databases was 
provided by legal authorities for public consulting and should thus not be considered as the total 
number of incidents during this period.” With this caution, the study reported that: 

“Tail strikes followed by aircraft damage [with] no injuries to persons on board were 
the outcome of 45.45% (n = 10) of incidents. In 27.27% (n = 6), there was no 
technical or operational consequence. In 13.63% (n = 3), the safety margins were 
reduced, while in 9.09% (n = 2), the crews were able to reject the takeoff. Only one 
runway excursion happened. 72.72% (n = 16) were incidents with minor damages, 
and 27.27% (n = 6) were serious accidents.” 
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2.3 Ideas about Risk Mitigation 

Santoni and Terhune (2000) made several suggestions for risk-mitigating procedures and systems: 

1) provide correct data to the flight deck (minimizing manual entries by ground personnel to control 
data entry errors); 2) provide clear and unambiguous displays (recognizing the hazard of 
substituting one datum for another such as ZFW for GTOW); 3) recognize and establish procedures 
for coping with time pressure and out-of-sequence operations; and 4) implement reliable data 
verification procedures. 

Santoni and Terhune further suggested that, to improve verification, manual performance data 
processes should require independent calculations performed by different persons (pilots, 
dispatchers, and/or operations agents). Most automated processes still involve data entry, at least to 
the FMS on the flight deck, and this data entry step should require verification of the inputs 
between the two pilots. The authors suggested that data verification procedures can reduce the 
likelihood of untrapped errors by “several orders of magnitude” (p. 18). 

This study concluded with examples of best, good, and poor practices for several aspects of the 
performance data process. Suggested best practices in the areas of data verification and error 
trapping included procedural requirements for pilots: 1) comparing the gross weight displayed in 
the FMS with a gross weight value calculated by ground personnel; 2) cross-checking V-speeds that 
have been manually calculated and entered by a pilot against those independently calculated by 
ground personnel, another pilot, or automatically calculated by the FMS; and 3) cross-checking a 
pilot’s FMS entries by another pilot. 

Laboratory of Applied Anthropology (2008) highlighted the limited effectiveness of cross-checks 
and other error-trapping procedures in mitigating performance data errors: 

“Even an input with cross check doesn't guarantee the absence of an error, as one of 
the studied incidents shows: the captain calls out the value to be input and confirms 
the input made by the [first officer]. However, the captain doesn't read the 
appropriate value, so calls out an erroneous value and the verification of input is 
ineffective” (p. 31). 

They also pointed out that a cross-check must verify not only the values that have been entered into 
a display unit but also the inputs used to derive the entries. They concluded, “Observations showed 
that there was no [error-trapping] based on a comparison of the three principle media: the final 
loadsheet, the takeoff card or laptop, and the FMS” (p. 66). 

These researchers viewed an automated takeoff performance monitoring system (TOPMS) to alert 
pilots in real time about inadequate acceleration during the takeoff roll as the “ultimate barrier” (p. 
12) to adverse consequences from a performance data error. This echoes the recommendations of 
the Transportation Safety Board of Canada (TSBC) from its investigation of the Halifax accident as 
well as earlier recommendations from the U.S. National Transportation Safety Board (NTSB, 

1982). Industry efforts to develop such a system date back at least 50 years, yet to date no such 
system is employed commercially. We evaluate the history, viability, and effectiveness of the 
TOPMS in the Discussion section. 

Hughes & Godley (201 1) proposed several risk mitigation guidelines: 

“For airlines, it is important to look at the ways errors can be introduced into the 
process and determine if the procedures currently in place prevent these errors from 


occurring or provide sufficient opportunities for errors to be detected. Procedures 
need to take into account the entire process and recognize that errors may occur at all 
stages of pre-flight preparation.” 

Ideally, procedures relating to the calculation and entry of takeoff performance parameters should 
take into account the following: 

• An independent calculation or cross-check of the takeoff performance data is conducted by 
another crewmember. 

• Where possible, the data is verified using multiple sources. 

• When verifying the data, both the values used to make the calculations and the values that 
are calculated are checked. 

• There are procedures in place in the event the primary aircraft system used to calculate 
takeoff performance parameters is unavailable. 

• The roles and responsibilities of all crewmembers are clearly delineated (p. 71-72). 

Henriqson, Winsen, Saurin and Dekker (2010) addressed the limitations of certain cross-checking 
procedures and their reliability in trapping performance data errors: 

“One way in which flight crews often cross-check data card values is through 
validation of each step of the procedure. In this case, the captain will check on the 
laptop all of the values inserted by the first officer, following the same steps used to 
perform the original takeoff calculations... An analogy can be the mathematical 
validation of a simple product operation. For instance, if we type in a calculator “2” 

“times” “3” “equals” (=6) and we wish to check the accuracy of this calculation 
(or the outcome), we do this by following the same procedure “2” “times” “3” 

“equals” once more. We rather cross-check the operation that leads to the “6” than 
the validity of the “6” as the outcome, or the “2” and “3” as inputs. In this 
manner, when the captain is checking or typing the same values in the same order in 
the laptop or in the FMC, he is validating the process rather than the outcome, the 
[gross weight] or the takeoff speeds produced. This is why double cross-checking or 
parallel calculations are not independent and thus not fully efficient.” 

In a symposium discussion of performance data errors, Jarvis, Todd, and Burian (2010) touched on 
means of making the trapping of errors more effective and reliable. They suggested that verification 
would become more of an “actual check” if the personnel were to perform their cross-checks 
without already “knowing the answer.” Another way to enhance the effectiveness of error-trapping 
was “slowing things down” (p. 30). 

The Federal Aviation Administration (FAA) addressed the difficulty of implementing automated 
error-trapping routines in some existing FMS models in a June 6, 2005, letter to the National 
Transportation Board responding to NTSB Safety Recommendation A-05-04 (FAA, 2005). The 
NTSB had recommended that the FAA: 

“...[rjequire Honeywell to modify its flight management system [FMS] software to 
prevent entry of airplane weights that would result in landing weights below ZFW or 
operating empty weight, and require all operators of airplanes with Honeywell FMS 
computers to incorporate this software modification” (NTSB, 2005). 
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The FAA responded, “There are a number of FMS manufacturers, each of which may have multiple 
FMS versions in their product lines. Each FMS version may have different safety vulnerabilities to 
data entry errors that affect takeoff and landing performance information” (FAA, 2005). 

NTSB Safety Recommendation A-05-03 asked the FAA to: 

“...[rjequire Honeywell to modify its flight management system [FMS] software to 
annunciate warnings to the flight crew when a takeoff reference speed is changed by 
a value that would impede the airplane's ability to safely take off, and require all 
operators of airplanes with Honeywell FMS computers to incorporate this software 
modification” (NTSB, 2005). 

However, the FAA replied on November 23, 2009, that: 

“...many part 25 airplanes are equipped with Honeywell FMSs that do not compute 
takeoff speeds. Those systems can detect certain erroneous entries. However, because 
there are no takeoff speed computational algorithms in the operational program 
software, a determination of "safe" speed by those FMSs is impractical. Because of the 
wide range in equipment and potential for errors at many points in the process of 
setting reference speeds, a single technical solution is not considered practical or 
effective in resolving these issues with current FMS installations” (FAA, 2009). 

NTSB Safety Recommendation A-05-05, asked the FAA to: 

“... [Require Honeywell to modify its [FMS] software either to inhibit manual entries 
in the gross weight field or to allow the takeoff gross weight to be uplinked directly 
into the FMS, and require operators of airplanes with Honeywell FMSs to 
incorporate this software modification” (NTSB, 2005). 

However, the FAA in its June 6, 2005, response to the NTSB replied, “For existing FMS 
airworthiness approvals... operators already have policies restricting weight entries to ZFW 
only. ..Therefore, it would not be necessary to retrofit the fleets to prevent gross weight entries” 
(FAA, 2005). 

In a March 30, 2009, memorandum (FAA ANM-1 11-09-006, 2009), the FAA provided guidelines 
for developers of newly certificated FMS to mitigate human error in pilots’ interactions with these 
systems. These guidelines are not mandatory and the FAA has not proposed requiring modification 
of existing FMSs already installed and operating in the current airline fleets. 

In these guidelines the FAA stated: 

“The FMS should not allow the flight crew to manually enter the airplane gross weight. 
Instead, the FMS should. ..calculate airplane gross weight from valid zero fuel weight and 
fuel-weight entries (or other similar logic), or. ..accept airplane gross weight entry through 
automated means, such as datalink or onboard weight and balance systems” (p. 2). 


Also: 

“[T]he FMS (should) incorporate error detection based on typical weight entries. 
Should the takeoff speeds not be representative of typical performance, then an 
annunciation should be presented to the flight crew. For example, given a valid gross 
weight, flap setting, etc., the FMS could compare the takeoff-speed entries with a 
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representative range, and annunciate to the flight crew any entry exceeding that 
representative range” (p. 4). 

Further, in its evaluation of emergent technology, the FA A stated that an onboard automatic weight 
and balance system “could interface with the FMS and transmit the measured airplane weights 
directly into the FMS” (p. 3). The potential role of onboard weight and balance systems as a risk 
mitigation to performance data errors was extensively discussed in a 2007 survey of aircraft weight 
and balance incidents by Netherlands Aerospace Laboratory (van Es, 2007). This accident and 
incident case study revealed similar error types and underlying factors as the French and ATSB 
studies. Van Es concluded, “The majority (more than 90%) of weight and balance problems 
identified in this paper could be eliminated if there was a system available to the flight crew that 
would do an automatic onboard weight and balance assessment” (p. 20). 

Reviewing the history of these systems, van Es found that government/industry efforts to 
develop an automatic aircraft weight and balance system went back to the 1940s but that an 
accurate and reliable system had not emerged from these efforts. As van Es reported, the 
NTSB recommended that the FA A sponsor or develop such a system as a result of the 
January 8, 2003, crash of a Beech 1900D turboprop at Charlotte, North Carolina; also, the 
French BEA stated in its report on the investigation of the December 25, 2003, crash of a 
Boeing 727 that: 

“...erroneous estimates of [performance data] parameters are quite likely during 
operations. Onboard autonomous systems are, however, available and they give an 
indication of the airplane’s weight and balance that is sufficient to attract the crew’s 
attention in case of an abnormal situation” (van Es, 2007, p. 20). 

Accordingly, the BEA recommended that civil aviation authorities “ensure the presence, on new 
generation airplanes to be used for commercial flights, of onboard systems to determine weight and 
balance” as well as require the retrofitting of this equipment to existing aircraft when technically 
feasible (van Es, 2007, p. 20). 

Van Es described the general design of an automatic aircraft weight and balance system using axle 
strain gauges on the nose and main landing gear, along with measurements of the aircraft’s attitude 
on the ground, to estimate the weight and CG of the aircraft. Design standards, including those for 
accuracy and reliability (see the discussion of FAA AC 20-161 , below), have established 
demanding criteria if the automatic system is to serve as the primary source of weight and balance 
information (e.g., using the automatic system to replace the usual methods of building up the 
aircraft’s total weight from the weights of the individual components such as cargo and fuel, and 
the aircraft’s CG from the loaded positions of these individual weight components). These criteria 
for use as a primary system are the ones that have been difficult to design and implement; the 
Netherlands Aerospace Laboratory (NLR) noted, however, that automatic weight and balance 
systems exist on some transport aircraft types and are available as a secondary source of weight and 
balance data (van Es, 2007). Finally, van Es proposed that an alternative automated system could be 
one that would: 

“rapidly weigh and automatically track passenger and baggage weight and location 
data as passengers board aircraft. The rapid development in different technological 
advances such as hand-held devices and wireless bar code scanners indicate that it may 
be feasible to compile actual weight data and account for the weight location, which 
can result in a reliable calculation of actual aircraft weight and balance” (p. 22). 
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The FAA provided guidelines for onboard aircraft weight and balance systems in Advisory Circular 
20-161 (FAA, 2008). In this document, the FAA conceived of the automated systems as replacing 
current methods based on calculating the weight and balance of the entire aircraft from the weights 
and locations of the individual load elements; as we have mentioned, this replacement would 
require high precision and accuracy. The Advisory Circular provides the levels of accuracy, 
reliability, and failure tolerance required for these automated systems to serve as the primary source 
of performance data as well as acceptable methods for installation and testing to obtain approval as 
well as for operating these systems in practice. 

In a June 15, 2004, final report, the Human Factors-Harmonization Working Group of the FAA and 
Joint Aviation Authorities (HF-HWG, 2004) proposed that the FAA take regulatory action and 
provide additional guidance material to enhance the consideration of flight crew performance and 
error in the certification of all related equipment and furnishings installed in newly certificated 
transport aircraft designs. This would appear to include equipment such as laptop computers, EFBs, 
and FMS that is used in the performance data processes, including those for error trapping and 
discrepancy resolution. In response, on February 3, 201 1 , the FAA published a Notice of Proposed 
Rulemaking seeking to establish 14 Code of Federal Regulations Part 25.1302. This proposed 
regulation states, in part (FAA, 2011): 

Flight deck controls and information intended for the flightcrew's use must: 

1 . Be provided in a clear and unambiguous manner at a resolution and precision 
appropriate to the task. 

2. Be accessible and usable by the flightcrew in a manner consistent with the 
urgency, frequency, and duration of their tasks. 

3. Enable flightcrew awareness, if awareness is required for safe operation, of the 
effects on the airplane or systems resulting from flightcrew actions. 

Operationally-relevant behavior of the installed equipment must be: 

1. Predictable and unambiguous. 

2. Designed to enable the flightcrew to intervene in a manner appropriate to the 
task. 

To the extent practicable, installed equipment must incorporate means to enable the 
flightcrew to manage errors resulting from the kinds of flightcrew interactions with 
the equipment that can be reasonably expected in service. 

The FAA received comments on the proposed rule until April, 2011. Final rulemaking is in a 
pending status. 

Three recent serious incidents related to performance data error, discussed below, were investigated 
and reported on by the Air Accidents Investigation Branch (AAIB) of the United Kingdom and 
provide additional information about air carriers’ establishment and use of error-trapping routines 
in standard operating procedures as well as pilots’ performance of these routines in practice. 

Airbus A330-243, G-OJMC, October 28, 2008, Serious Incident Report (AAIB, 2009a). Unable to 
use their normal tabular method for determining performance data, the flight crew requested that 
the dispatch department perform the calculations. The captain provided the information needed by 
the dispatcher over the telephone and the dispatcher provided the takeoff performance data, 
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including V-speeds, also by phone. The captain then handed the telephone to the first officer who 
independently obtained the takeoff performance data from the dispatcher. The two pilots compared 
the performance data and they were identical. 

For unknown reasons the dispatcher had used a GTOW of 120.8 metric tons rather than 210.2 
metric tons. The performance calculations based on the lighter weight resulted in a Vr speed that 
was 26 knots slower than the proper speed. The aircraft experienced degraded climb performance 
and handling during rotation and initial climb. The captain perceived that the performance was not 
correct and he engaged full thrust for takeoff which helped the aircraft complete the takeoff and 
climb maneuvers safely. 

The investigators learned about several missed opportunities for checking for errors and catching 
the dispatcher’s mistake. The system used by the dispatcher 

“was capable of calculating the aircraft’s [best lift/drag] speed. The aircraft’s [FMS] 
also calculates [this] speed independently of the performance figure provided by [the 
dispatcher], and so this could be used as a gross error check, provided that the same 
takeoff parameters were input to both systems. [However] , the function to calculate 
the [best lift/drag] speed had, for an unknown reason, been disabled on this 
operator’s [dispatch-based] system and they had no procedure requiring the 
[dispatch] -generated... speed to be passed to crews” (p. 3). 

Significantly, review of the flight data recorder data after the incident revealed that the aircraft’s 
actual weight and CG were automatically sensed and calculated by the aircraft’s onboard 
equipment. The correct data were passed to the flight recorder for post hoc use by the accident 
investigators,but not to the flight deck displays or flight crew. 

Airbus A340-642, G-VYOU, December 12, 2009, Serious Incident Report (AAIB, 2009b). The 
airline’s performance data process involved the pilots entering aircraft weight and loading data into 
the ACARS for transmission to the central load planning computer, with performance weights and 
speeds returned to the flight deck (also by ACARS), then manually transferred to the FMS by the 
pilots reading from the ACARS screen and typing into the FMS. There was a late change in the 
load and this disrupted the crew’s preflight preparations and required them to obtain a new flight 
plan and delay their inputs to the ACARS system for transmission to the central computer. A pilot 
then mistakenly entered the aircraft’s landing weight instead of its TOW into the ACARS, which 
caused the central load planning computer to generate incorrectly low V-speeds and reduced thrust 
values. The pilots discussed what appeared to be an abnormally low thrust value calculated by the 
central computer but they did not resolve the issue. The weight entry error was not detected in 
either the automated central functions or during the flight crew’s entry and review of the data. The 
aircraft was rotated early and had inadequate airspeed and climb performance during the initial 
climb. Later, the pilots realized the error upon review of their ACARS inputs to the central 
computer. 

The investigation revealed that this airline had incorporated several error traps into its standard 
operating procedures (SOPs). The operator’s SOPs required crews to request the performance data 
from the central computer, using the estimated weight, but to refrain from entering the centrally 
calculated V-speeds and other data into the FMS. Then, after the final loadsheet was received, the 
actual TOW would be verified against the estimated value used for the performance data request 
before being entered into the FMS. 


16 


The SOPs also required the loadsheet procedures to be led by the captain and checked by the first 
officer and the performance data request procedures to be led by the first officer and checked by the 
captain. According to the incident report, “Nine independent cross-checks were built into the 
procedures including a requirement for the actual TOW to be written on the [performance data] 
printout alongside the TOW used for the calculation to provide a gross error check” (p. 2). 

However, as the AA1B observed: 

“The late change. ..disrupted the usual loadsheet and performance procedures, which 
were conducted out of sequence. Because of the late change, the crew decided not 
to calculate an estimated takeoff weight for an initial [data] request, preferring to 
wait for the loadsheet to use the actual value. The landing weight entered in the 
takeoff weight field of the [data] request would have been acceptable as a takeoff 
weight on the Airbus A340-300, which the crew also flew. The operator considered 
that this might have been why the crew was not alerted to the error. Because no 
[data] was requested using an estimated takeoff weight, no gross error check could 
be made against the loadsheet takeoff weight” (p. 2).” 

Airbus A321-21 1 , G-N1KO, April 29, 2011 , Serious Incident Report (AAIB, 2011). During preflight 
preparations, the captain mistakenly read the ZFW value on the load sheet as the TOW, transferring 
the incorrect figure to the navigation log as required by company procedures as well as vocalizing it 
to the first officer. Procedures then required the captain to compare this actual TOW value (which 
was incorrect) with the estimated TOW already printed on the log. However, he mistakenly 
compared with the estimated ZFW on the log, allowing him to believe he had satisfied this cross- 
check. The captain then correctly entered the ZFW into the FMS (the FMS was designed to accept 
only the ZFW) so the FMS’s internal weight and V-speed calculations would have been correct. 
Despite the correct data being in the FMS, procedures required the crew to enter the TOW into a 
laptop performance computer to obtain V-speeds and other performance data. In this case, the 
captain entered the incorrect TOW and obtained a Vr speed value more than 20 knots slower than 
the correct value for the aircraft’s actual weight. The first officer was required to perform an 
independent calculation of the V-speeds using the laptop, with the two pilots comparing their 
results, prior to manually entering the performance data into the FMS. The incident report does not 
detail whether this independent cross-check procedure was performed by the crew but the first 
officer had obtained the same incorrect value for TOW from the captain. The airline had established 
a final error-trapping procedure for the crew, prior to departure, to cross-check the best lift/drag 
speed calculation by the laptop (which would have been using the incorrect weight) against that 
calculated by the FMS (which had the correct weight and would have calculated a much faster 
speed). However, the pilots apparently omitted this procedure. 

During takeoff rotation the flying pilot noticed that the stick felt heavy and also that the flight deck 
display of minimum safe speed was increasing rapidly (this value is calculated by the FMS using 
angle-of-attack information that is only available in flight). In response, he reduced the aircraft’s 
pitch attitude to gain airspeed more quickly. The aircraft climbed slowly but achieved a safe altitude. 

Finally, in the report of its investigation of the March 20, 2009, A-340 accident at Melbourne, 
Australia (ATSB, 2011), the ATSB provided a detailed description and analysis of multiple error- 
trapping procedures that the air carrier had established (similar to those identified in the above 
incidents). The investigators found that none of these procedures trapped the pilots’ entry of an 
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incorrect weight value into their laptop performance computer, which then propagated to incorrect 
V-speeds, premature rotation, tailstrike, and severely degraded climb performance. 

Considering human factors related to the reliability of error-trapping procedures, the ATSB 
determined that distractions during preflight preparations from competing operational tasks and 
interruptions by other personnel may have been factors in the pilots’ failure to perform some of the 
procedural cross-checks. Further, the pilots’ expectations that the calculated performance values 
would be correct may have been factors in their failure to catch the incorrect value. In one of 
several instances in which the error could have been trapped, a cross-check between the weight 
value in the FMS and the corresponding value they had copied from the laptop to the company 
flight plan form, one pilot vocalized the incorrect weight value that he read from the flight plan 
form but quickly “corrected” the value into a weight that was more consistent with their 
expectations and nearly matched that in the FMS (p. 81). The ATSB summarized: 

“the crew’s non-detection of the erroneous takeoff weight entry in the EFB was 
multifaceted, and reduced the effectiveness of the procedural checks that could, 
individually, have detected the error. It is possible for errors to pass undetected 
through various checks, which is why most procedures incorporate multiple 
independent checks to verify critical information” (p. 82-83). 

Considering the set of error-trapping procedures as a system and its overall reliability and 
effectiveness, the ATSB stated: 

“The conduct of the takeoff weight comparisons within the takeoff performance 
error check, takeoff data check, and loadsheet confirmation procedure, within a 
relatively short period of time, may have been perceived by flight crew as redundant. 

Given that on the accident flight, the takeoff performance calculation was based on 
the final, and therefore unchanging weight figures, the risk that the three, close 
proximity checks might appear superfluous was heightened. That might explain to 
some extent why only the final loadsheet confirmation procedure was completed. 

Standard operating procedures are typically designed on the basis that information 
flow into the cockpit is sequential and the procedures are conducted in a linear 
fashion based on this sequential information flow. Research has shown that the 
information flow into the cockpit during line operations typically does not follow the 
sequence upon which the procedures are based. This increases the likelihood that, 
following a distraction, the flight crew will re-enter a procedure at an incorrect point. 

The sequence of delivery of information may also lead the crew to believe that a 
check is no longer required” (p. 86). 

This literature review reveals that many aspects of the problem of using incorrect load and 
performance data have already been examined, with largely consistent findings. Consequently, we 
decided to focus our own study on aspects not thoroughly explored previously. In the Discussion 
section we will draw upon both our own findings and these previous studies to propose practical 
ways to reduce vulnerability to errors and ways to mitigate the consequences of errors. 

3. Method 

To extend our knowledge of how airlines generate and use load and performance data, we contacted 
personnel from five airlines (a regional turboprop operator, two large worldwide passenger carriers, 
and two large passenger carriers). These individuals helped us develop descriptions of the flow of 
information in the overall system, the specific steps involved, and the persons who normally 
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perform those steps. The discussions also helped us identify error vulnerabilities, and procedures 
and equipment used to catch errors. 

To gain information beyond that provided by the accident and incident case studies described in the 
previous section, we also developed a database of related events from information in the ASRS. 

The ASRS is a voluntary U.S. system that allows flight crews, air traffic controllers, maintainers, 
flight attendants, and operations personnel to confidentially report issues regarding safety. The 
information provided in these reports cannot be used by the FAA as evidence for regulatory 
violations or sanctions. Further, personnel who provide an ASRS report receive immunity from 
sanctions that the FAA may assess related to a violation case (based on other evidence) for the same 
event as long as the violation was unintentional and did not involve an aircraft accident or criminal 
act. The ASRS received over 37,000 reports in the year 2000 and over 48,000 in 2009— the time 
period accessed for this study (J.B. Moya, ASRS, personal communication, February 15, 201 1). 

3.1 Study Scope, Keyword Search, and Sampling 

Our goal was to obtain event descriptions involving errors in entering, calculating, handling, 
transmitting, receiving, executing, and applying all of the data elements of aircraft weight, balance 
and performance information. We wanted to include procedures, actions taken or not taken by any 
person in the system generating or using this information. To obtain a large enough cross-section, 
we defined the scope for our data search as U.S. Part 121 (scheduled passenger and cargo) air 
carrier operations from January 2000 through October 2009. To obtain cases related to aircraft 
performance data, we searched the narrative and synopsis fields of all of the ASRS reports within 
this scope using the keyword search terms: 

• Weight OR Wt Or Bal% And Error 

• ZFW OR “Zero Fuel” 

• Rotat% AND (Weigh% OR Set%) 

• Vr 

• Laptop 

Note: The use of partial words and the “%” symbol in the keyword searches allowed 
the ASRS search engine to identify relevant cases despite variations in word endings 
in the database entries. 

These keyword-based selection criteria were not mutually exclusive (duplicates had to be 
eliminated manually) and not exhaustive of all cases within the ASRS database that would have 
been relevant to our study. However, from review of the reports obtained using these criteria, these 
selections appear to provide a reasonable cross-section of the performance data errors in the ASRS 
database. 

The ASRS accepts reports from a wide variety of personnel functions within the airline industry, 
although not from the load planning, load control, ramp, gate, and station operations personnel who 
perform most of the ground functions related to aircraft performance data. We specified the 
selection of this set of events to comprise reports provided by the following positions and job 
functions as defined by the ASRS: 

• Captain/Pilot flying 

• Captain/Pilot not flying 

• First Officer/Pilot flying 

• First Officer/Pilot not flying 
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• Flight Engineer 

• Company Dispatcher 

• Check pilot 

• Instructor 

A total of 1 ,1 16 ASRS reports met the keyword and reporter selection criteria. Review of those 
reports revealed that many did not actually involve performance data errors. Accordingly, one of 
the authors, an airline pilot, evaluated each report for relevancy, resulting in 246 reports after 
deleting duplicates. From this set, a random sample of 100 reports was selected as the database for 
statistical analysis. We used the remaining 146 reports that met the selection criteria to provide 
additional illustrative examples in the sections that follow. 

3.2 Error Identification 

The 100 ASRS reports in the analytical sample were reviewed by one of the authors (an airline 
pilot) to identify discrete errors described by the reporter in the narrative and synopsis text sections 
of the ASRS report. The process of error identification was reviewed by another author (a human 
factors researcher) and the two authors used a discussion and resolution procedure to converge on 
and reach agreement on a total of 1 12 errors in the 100 cases. 

3.3 Variable Definition and Coding 

For each of the 100 reports in our database, we supplemented the data elements that the ASRS 
codes in its database (for a detailed list of these, see ASRS, 2012) with several of our own data 
elements or variables. One of the authors, an airline pilot, coded values for these variables based on 
review of the narrative and summary text of each ASRS report. 

The locus of error: classifies the place in the performance data process where the error occurred as 
being either among ground personnel performing functions external to the flight deck or the flight 
deck personnel (all of the latter were pilots in these cases). 

The subcategory of personnel: codes the ground locus of error, for those reports for which more 
detailed information was available, into central load planning (based at the airline’s headquarters or 
one of its operational centers), station operations (an office located at the airport from which a flight 
departs or arrives), and ramp/gate personnel who process passenger boarding, process baggage and 
cargo loads, and service the aircraft at the station. 

The process step, actor, and type of error: identifies the place in the airline performance data 
process at which each error occurred. Based on our discussions with airline personnel and our own 
industry knowledge and experience, we first developed a list of the steps involved in generating 
performance data, transmitting them to the flight crew, entering them into the FMS, and setting 
flight deck controls based on these data. The process steps that we identified were: 

• Forecast load limitations (e.g., weight restrictions ). This function is performed by ground 
personnel, usually several hours prior to departure time. It involves using the passenger 
pre-bookings, planned baggage count based on the number of booked passengers, 
anticipated cargo, the aircraft’s basic operating (empty) weight, weather at departure and 
arrival stations, and predicted runway and other environmental factors to forecast the 
maximum allowable TOW for the flight and whether the planned load can be 
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accommodated. If not, the load will be adjusted as required through a weight restriction 
(maximum load value) being assigned to the flight. 

• Revise forecasts based on changes in weather, temperature, runway, fuel requirements. 
Closer to the time of departure these factors that can affect the maximum TOW (and 
consequently the load that can be accommodated on the flight) must be reviewed for 
changes and any weight restrictions must be adjusted accordingly. For example, if the air 
temperature increases, the aircraft’s engines will not develop as much thrust and its wings 
will not develop as much lift, therefore the load limit may have to be revised downward. 

• Obtain actual cargo weights. Before departure time the cargo that is planned to be 
loaded aboard the flight is aggregated and separated from that assigned to other flights, 
usually in a facility that is remote from the ramp area where the aircraft is parked. The 
cargo is placed on carts, pallets, or inside containers as appropriate for the aircraft. 

These load units are weighed or the weight of each unit is summed from the weight of 
each cargo item included. The weights of the individual items are derived either by 
weighing them at the cargo facility or by using the weight of each package or container 
that is listed in its shipping papers (reflecting that the items were weighed earlier, such 
as at their point of origin). 

The cargo units that are to be loaded onto the aircraft are listed on a cargo manifest (paper 
form or computer file) that is transmitted to the loading ramp either with the cargo itself or 
by other means. Individual pieces of cargo may be scanned before being containerized or 
placed in carts and the entire unit or container may be scanned to facilitate tracking. 

The total weight of cargo destined for each bin in the belly of the aircraft is transmitted 
(by manual entry on a form, manual entry in a computer, or automatically by the cargo 
load control system) to the ground personnel or pilots who will be using the cargo weight 
to derive the weight and CG (balance) of the aircraft. Passenger baggage may be 
aggregated, unitized, documented, and delivered to the aircraft in a similar way, although 
it is usually not weighed; instead, most airlines have approval to use an average weight for 
each piece of baggage so either at this point in the process or in the calculation step (see 
below) the total baggage weight is derived by multiplying the approved estimated average 
weight by the number of pieces. Baggage counts are also subject to last-minute changes as 
late-arriving passengers enplane, others miss their connections, etc. 

• Obtain actual passenger counts/weights. As passengers board the aircraft at the gate their 
boarding passes are collected; scanned, manually entered into a computer, or checked off 
a list to reflect actual boarding; and then reconciled against the list of booked passengers 
to verify that the passenger is boarding the correct aircraft. The total count of boarded 
passengers is transmitted (by manual entry on a form, manual entry in a computer, or 
automatically by the passenger boarding control system) to the ground personnel or pilots 
who will be using the count to derive the weight of the passengers. As with baggage, most 
airlines use an average passenger weight approved by the FAA so the total weight of the 
passenger load is derived by applying this approved estimated average value to the 
passenger count. 

• Calculate weight/balance values. Prior to takeoff, the aircraft’s weight and balance values 
are calculated for use in subsequent performance calculations. If they are not 
automatically transmitted from the earlier functions of counting or aggregating the loads 
(see above), the individual components of the load (passengers, baggage, and cargo) are 
manually entered into a calculator, computer, or tabular reference by the ground personnel 
or pilots performing this function. The weights of these loads are added together with the 
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basic operating weight of the aircraft to derive the ZFW of the aircraft. The weight of the 
fuel is derived from fuel quantity indicators and/or by multiplying the planned fuel load in 
gallons by the weight of fuel per gallon. The sum of the ZFW plus this fuel weight (less 
the fuel weight planned to be consumed during taxi-out for takeoff) is the GTOW. For 
further performance-planning purposes, the projected gross landing weight (GLW) is 
derived by subtracting the fuel weight that is planned to be used from takeoff to landing 
from the GTOW. 

Similarly, each component of weight to be loaded aboard the aircraft is combined with information 
about its planned location on the aircraft to derive the CG position, or balance, of the loaded 
aircraft. Separate balance calculations are made for the aircraft’s status at takeoff and landing (the 
difference being the burn off of fuel during the flight). Ground personnel or pilots perform the 
balance calculations using hand calculations, tabular references, calculators, or computers. The 
calculated weight and balance values are then entered manually, or automatically transmitted, to 
those persons performing the next steps of the process: 

• Verify weight/balance against performance limits. Prior to takeoff, the weight and balance 
values must be compared to the limitations that were established for safe operation of the 
aircraft by the aircraft manufacturer and certification authorities. Some of the relevant 
comparisons are the calculated ZFW against the maximum ZFW limit (which provides 
safe margins for the aircraft structure, such as wing/body attachments and landing gear); 
calculated GTOW against the maximum GTOW limit (which constrains allowable TOW 
for the specific runway length, wind, temperature, and obstacles in the area to assure safe 
margins in the event of contingencies such as engine failure); calculated GLW against the 
maximum GLW limit (which provides safe margins for the structural loads imposed by a 
hard landing); and calculated CG position against the forward and aft CG limits (which 
provides safe margins for aircraft stability and control). 

These comparisons may be performed by ground personnel or pilots using manual 
methods (e.g., comparing the calculated ZFW to a memorized maximum ZFW limit), 
automation (e.g., a computer program that accounts for the effects of winds and 
temperature on takeoff performance and checks the aircraft’s climb gradient over pre- 
stored obstacle positions and heights for both all-engine and engine-failure 
contingencies), or a combination of these methods. Each calculated weight/balance 
value must be re-checked against its respective limitation whenever a load element 
changes (e.g., last-minute addition of ten passengers in the aft section of the cabin) or 
an environmental factor changes (e.g., air traffic control assigns the flight to a different 
runway for departure). 

To prevent large workload increases from being imposed by very small changes, many 
airlines have established an allowable variance for changes below which the limitations 
need not be re-checked in order to streamline operations. To use this system, the airline 
reflects assumptions of additional weights of various load elements and locations on the 
aircraft in its performance calculations for the flight, providing an additional buffer to 
safety margins that can be used up to the limits of what was assumed in the calculations 
and informs its personnel of the thresholds beyond which the provided calculations cannot 
be used (e.g., no more than 1 10 passengers in the aft cabin or maximum allowable 
increase in GTOW of 12,000 pounds). (Airlines should be careful to emphasize to 
personnel that changes greater than threshold values must be re-checked, lest a cavalier 
attitude about re-checking in general emerge.) 
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• Calculate V-speeds, trim settings, engine thrust, and flap setting. Prior to departure, the 
calculated weight/balance and the known environmental values are used to derive the 
information that the pilots need to apply to the upcoming takeoff: the V-speeds they will 
use to make the reject/continue decision for an engine failure during the takeoff roll (VI), 
rotate the aircraft at the proper time to provide the required runway and climb 
performance (Vr), and climb safely in the event of an engine failure (V2); the trim setting 
for the horizontal stabilizer that will provide controllability during rotation/climb; the 
engine thrust value that will provide the required runway and climb performance (most 
takeoffs are performed with the thrust reduced below the maximum available from the 
engines to reduce aircraft noise and wear on the engines); and the flap setting that will 
configure the wing to provide the needed lift at the planned rotation and climb speeds. 
These values are obtained or calculated by ground personnel or pilots using tabular 
references or computers. 

• Transmit weight/balance, V-speeds, and control settings to the flight deck. If the values 
derived from the above calculations are not performed by the pilots, these data must be 
provided or transmitted to the flight deck prior to departure. This can be done by 
handing a paper form, such as a load manifest that includes these performance data, to 
a pilot before closing the passenger entry door. Alternatively, it can be uplinked to a 
flight deck printer or an electronic display to be viewed by the pilots or, in some 
installations, uplinked directly to the FMS to be reviewed and accepted by the pilots 
without manual entry. 

• Enter weight/balance values into FMS. If the weight and balance data (e.g., ZFW, GTOW, 
CG location) are not uplinked directly into the FMS, they must be manually entered by a 
pilot who visually references the source for these data on the flight deck (e.g., printed load 
manifest, onboard laptop performance computer, or other display unit), locates each 
desired data element (e.g., ZFW) on the source document, then manually enters the same 
number into the FMS using its keypad (to enter the number in a scratchpad) and soft keys 
(to direct the number that was keyed into the scratchpad into the data field reserved by the 
FMS for that same data element such as the second line on the left-hand side of the FMS 
display, for ZFW). We note, and will discuss later, that some airlines’ procedures require 
the pilots to enter the forecast weight data (see above) into the FMS early in the pre-flight 
preparations to facilitate FMS entries and calculations then override these values with the 
final weight data that are subsequently provided just before pushback or during taxi-out. 

• Enter V-speeds, trim settings, runway temperature, flap setting, etc., into FMS. Prior to 
departure, the pilots must use their source documents to enter these data into the FMS as 
well. Some FMS are capable of internally calculating approximations to the V-speed 
values based on pre-stored data about performance as a function of weight and other 
variables. For these, depending on how the airline has established its procedures, the pilots 
are required to accept/reject the V-speeds suggested by the FMS or override these 
internally generated values with manual keyboard entries. 

• Set bugs. On aircraft equipped with advanced FMS and electronic flight displays, the V- 
speeds will be automatically marked on the airspeed displays for the pilots to call out and 
use during takeoff. Other aircraft may be equipped with “bugs” (adjustable internal 
pointers or moveable external plastic markers) that the pilots manually position around 
their airspeed dials to mark the critical V-speed values. 

• Set trim. Trim values received or calculated on the flight deck must be manually set on the 
aircraft’s horizontal stabilizer by manually turning the trim wheel or operating electric 
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trim switches. To do this the pilot visually references the desired trim value reflected on 
the performance data source document and operates the trim control to match the trim 
indicator (a gauge, pointer, or digital display reflecting the actual position of the 
horizontal stabilizer) to the desired trim value. 

• Set flaps. Similarly, the flaps must be extended prior to departure to the setting that will 
provide the required takeoff performance as specified in the performance data calculations 
received or calculated on the flight deck. To do this the pilot visually references the 
desired flap setting reflected on the performance data source document and moves the flap 
control to match that setting, also cross-checking the flap indicator (a gauge, pointer, or 
digital display reflecting the actual position of the flaps). 

For each of these process steps, we identified the actors, or job functions, who might be involved in 
that step of the process (e.g., ramp agent, gate agent, central load planner, station operations agent, 
or pilot). The specific actor who performs each function varies depending on how each airline 
designs and implements its procedures and systems. (See Figures 1-3 in the Results section for a 
depiction of three variations in airline performance data system designs.) We then developed a list 
of the types of errors that might in principle be made by the actors in these process steps, reflecting 
our own knowledge of the process and discussions we held with airline personnel. The error types 
(e.g., failure to enter, erroneous entry, failure to cross-check) are descriptive. We attempted to be 
comprehensive, though of course we may have missed some steps in the process (at a very detailed 
level) and some types of error. For each error we coded the step of the process where the error 
occurred, the actor committing the error, and the kind of error. The matrix of process steps, actors, 
and error types resulting from this evaluation is provided in Table 3 in the Results section. 

Error trapping was coded for each error in several ways. An error was coded as having been 
trapped if it was caught and corrected before the flight was exposed to the risk generated by the 
error. For example, an incorrect flap setting was considered to have been trapped if the flaps were 
reset to the correct extension prior to takeoff, which is when an incorrect flap setting can lead to 
tailstrike, inability to climb, etc. 

For those errors in the sample that were trapped, we identified and coded whether the trapping was 
performed by : 1) the actions of personnel who were following established procedures (procedural 
trapping); 2) the actions of personnel not specifically mandated by established procedures (non- 
procedural trapping); or 3) the functions of technological systems as they automatically trapped 
errors or enabled personnel to trap them (technological trapping). 

To identify an upper boundary for the potential contributions of error trapping functions in the 
performance data processes, we also subjectively evaluated whether each error could have been 
trapped by procedural or technological interventions. For these latter two codings, one of the 
authors performed an informed, subjective evaluation by considering the full range of current 
procedural cross-checks, verifications, and checklists as well as technological automatic error- 
trapping, warning, and alerting systems either known to be in current use or projected in the 
literature to be a possible future development. (We included only future systems that are in 
principle well within current technology capabilities— no far-out systems only generically 
envisioned.) The criterion for coding an error as “trappable” by procedural means was that any one 
or combination of the current or potential procedures would have trapped the error if the procedures 
had been properly established and were reliably executed. Similarly, the criterion for coding an 
error as “trappable” by technological means was that any one or combination of current or potential 
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systems would have trapped the error if these systems were properly designed, functioned reliably 
in actual use, and operated properly and reliably by the personnel interacting with them. 

The role of cognitive and other human factors in these errors was evaluated subjectively by two of 
the authors (an airline pilot and a human factors researcher) using the case narratives and synopses 
for each report. The coding results were compared and any differences in coding were discussed 
until agreement was achieved. Coders decided whether any of the following contributed to the 112 
errors: the discrepancies related to the error not being salient to the persons involved; time pressure 
in the situation at the time of the error that was recognized by the persons involved; rushing; failure 
to cross check; disruption of a normal habit pattern, a normal habit pattern interfering with the need 
to perform an unusual action (habit capture); expectation bias; fatigue; momentary workload spike 
at the time of the error; distraction from other stimuli or events at the time of the error; prospective 
memory failure; failing to respond proactively; and confusion. 

We further evaluated each error as to whether the persons making the error had received incorrect 
information from an earlier step in the performance data process. For example, a pilot’s entry of the 
wrong V-speed into the FMS was coded as being based on incorrect information if the V-speeds 
were calculated using incorrect weight values provided to that pilot by another person or an 
automated system. 

We made a separate evaluation for each error as to whether it involved late or revised performance 
data. This was a subset of incorrect information. For example, a flight departed with the wrong V- 
speeds because the final or revised weight was not received on the flight deck until after takeoff. 

Erroneous use of preliminary data was coded if the flight departed using the preliminary 
performance data for weights and/or V-speeds (produced during the flight planning process and 
sometimes used on the flight deck to streamline operations) rather than the updated performance 
data based on the final passenger counts, baggage counts, cargo weight, and other load elements. 

We evaluated the consequences of each error by coding each error into one of five categories, 
using an informed subjective projection of the actual potential effects of the performance error 
upon flight safety: 

• Major adverse consequences— coded to errors that resulted in aircraft damage (e.g., tail or 
fuselage strike on runway); handling/controllability problems (e.g., uncommanded pitch-up 
prior to Vr or difficulty rotating the aircraft at Vr); significantly reduced performance (e.g., 
aircraft lifted off near the end of the runway, climbed sluggishly, was unable to maintain 
safe minimum airspeed at the planned cruise altitude, or landed hard); or violations of 
aircraft structural or performance limitations leading to potential damage or reduced safety 
margins in the event of contingencies, such as turbulence or engine failure, that fortuitously 
did not occur on the subject flight. 

• Minor consequences that could have been major in other circumstances— coded to errors 
that had no actual major adverse consequences but given changed circumstances such as a 
shorter runway the consequences likely would have been major. 

• Minor consequences— coded to errors that we evaluated as having no likely major adverse 
consequences under all conceivable circumstances. 

• Trapped— coded to errors that were caught and corrected prior to the flight being exposed 
to the consequences of the error. 
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• Linked to additional error— for those 12 cases in the sample in which we identified two 
distinct errors, the first error in the sequence was given this coding if the consequences in 
the case were not realized until the second error was committed. The consequences for the 
case were coded to and represented by the second error in the sequence. 

4. Results 

4.1 Information from Airlines 

We talked informally with personnel from five airlines— a regional turboprop operator, two large 
worldwide passenger carriers, and two large passenger carriers— to gain insight about their 
concerns about generation and use of incorrect load data and procedures to prevent and trap errors. 
The information from these discussions is summarized below. 

4.1.1 Counting/Weighing 

At one airline, a regional turboprop operator, a flight attendant provides the pilots with a passenger 
count by manually marking the occupied seats on the form and writing the total at the bottom of the 
form. The flight attendant is required to have compared this onboard count with the count provided 
by the gate agent, resolving any discrepancies before bringing the form to the flight deck. For the 
baggage and cargo weight values, “cargo planning” personnel provide these data to the flight deck. 
The planned values are provided about 30 minutes prior to departure and an update of final values 
is provided about 10 minutes prior. 

At another airline, a large worldwide passenger carrier, the overall load control process flow begins 
with the gate agents scanning or manually entering the number of boarding passengers into a 
computer (depending on the station’s equipment). Under the automated system, the gate agents are 
required to reconcile the passengers who have checked in but not boarded: Are they wandering in 
the terminal or are they aboard the airplane without having been properly entered? The agents must 
resolve the issue. They eliminated the flight attendant’s passenger count several years ago in favor 
of the reconciliation provisions of the new system. 

At this airline the cargo and baggage counts/weights are scanned or manually entered. This may be 
done miles from the aircraft in a remote cargo facility. Checked-in items are uplinked to a central 
load document, the “staging guide.” This provides a payload value for dispatchers and load 
planners to use for flight planning purposes. As part of the automation process the company 
established a cutoff time for accepting cargo and baggage, as opposed to the previous system in 
which they accepted baggage and cargo right up to departure time. This has been a great aid in 
reducing errors because it relieves time pressure and reduces the opportunity for error on the ramp. 

The cargo staging document that was prepared remotely is then printed at the ramp and the ramp 
agents are required to reconcile the items that are physically present on the ramp, prior to loading, 
by checking off each item on the list. A ramp agent will lose his job if he intentionally loads 
something that is not on the loading sheet. (We note that this is a strong incentive not to 
intentionally load items incorrectly to save time, but of course it does not prevent unintentional 
errors of this sort.) If an item on the sheet is not loaded, or if it is removed from the aircraft prior to 
departure, the computer system will not allow that item to be recorded as loaded on another aircraft 
until it is removed from the staging guide for the original flight. 

Reconciliation of actual load with documented load is accomplished by recording the bin number or 
marking a “hold off code” if the item is not to be loaded, including the reason it was withheld from 
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the aircraft (time, space, damage, etc). Then, the ramp personnel can attempt to finalize the 
document on the computer terminal. The load is considered validated if all the asterisks by the 
individual items have been changed to bin numbers or hold off codes. The document cannot be 
finalized for flight release until this is accomplished. This process is much more organized than it 
used to be at this airline. The computer checks all cargo related limits (bin weight limits, CG, etc.) 
and then it will let the ramp supervisor electronically sign the document. 

At another airline, a large passenger carrier, the process begins with a load planner in central load 
planning/dispatch producing a load plan for the lead ramp agent to use for loading the aircraft. 

When the warehouse accepts cargo it is weighed at that location. The weight is entered on a cargo 
manifest and the weight of the item is combined with weights of any other items on the cart to make 
up the cart weight. With the cart weights established the station can then load the aircraft according 
to the load plan. If there is a change during the loading process— such as the captain deciding that 
more fuel is required, necessitating removal of some cargo to offset the weight of the fuel— the 
ramp agents can look up the weight of the cart(s) to be offloaded and adjust the load plan. 

The flight crew receives final numbers including the aircraft’s basic aircraft operating weight plus 
accepted cargo. The lead agent then tallies the bag count (regular/heavy/gate-checked) and cargo by 
bin location using a handwritten form and radios the cockpit with the counts. The lead agent calls 
the crew back with any changes after all doors have been closed. The passenger count comes from 
the gate agent. The flight crew enters the data (basic operating weight plus cargo weight, bag count, 
and passenger count) in a laptop performance computer and then finally enters the performance data 
(ZFW, V-speeds) in the aircraft’s flight management computer (FMC). 

One captain from this company feels that having a direct voice connection from the ramp to the 
cockpit for the final numbers avoids the confusion and delay that can arise from working through 
an intermediary (such as central load planning or local station operations). It is possible, though, 
that an error could creep into the system as the bag and cargo numbers are passed from the agents 
doing the loading to the lead agent who provides there numbers to the cockpit. 

At another airline, a large worldwide passenger carrier, the pilots obtain the planned values for 
payload, ZFW, fuel load, and GTOW on the flight plan they receive from the dispatch 
department. There is a central load planning function that performs all of the performance 
calculations and generates a weight manifest document, including performance weights and V- 
speeds, to the flight deck printer by ACARS prior to pushback. The pilots are not required to 
reconcile differences between the planned weight values on the dispatch release and the final 
weight values on the weight manifest. 

At most stations the passenger count is produced automatically as a result of the passenger boarding 
documents being scanned at the gate. The pilots receive a passenger load reconciliation document 
via ACARS message to the flight deck printer. The procedure for flight attendants to perform a 
passenger count has been eliminated where this automated passenger-boarding control and 
reconciliation system is operational. At other stations, the flight attendants are required to provide 
the pilots with a passenger headcount. Where performed, the pilots are required to use the flight 
attendant count to make performance data adjustments but they are not required to reconcile 
differences between the flight attendant count and the one generated by the central load planning 
system as shown on the weight manifest. 
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4. 1.2 Calculating 

At the regional turboprop airline, the pilots use a company-tailored handheld computer to enter the 
passenger counts and cargo/baggage weights and obtain aircraft weights/V-speeds. At another 
airline, one of the large international passenger carriers, the calculations are performed in the 
central load planning department/function. The central load planning computer must receive 
closeout messages from the gate and ramp before it can generate the final performance data for 
transmission to the pilots. The airline allows the flight to push back and begin taxiing while the 
closeouts are being received and the final data are being prepared. 

Since 2005, this airline has been using an automated weight and balance system. It has 32 
automatic checks before it will allow the final weight form to be sent to the cockpit. These 
include checks of all load limitations and CG. Humans are not involved in the system except on 
an “exception basis” such as a fuel system minimum equipment list (MEL). The automated 
system would turn on a red flag for the load planner to read the fuel MEL and it would not allow 
the flight to depart until the load planner acknowledged the MEL with an electronic signature. 
There are no calculators involved in the central load planning process. Everything is done on the 
computers with no entries made by the load planners (though ramp and gate agents still make 
some manual entries). 

At one of the large passenger carriers, until recently the operations agent and ramp crew would 
produce a handwritten “load slip” that included the counts (heavy bags were counted as two or 
three bags). The paper slip was given to the pilots who used a laptop performance computer to 
complete the performance calculations. The pilots were expected to do a “logic check” (e.g., two 
bins worth of baggage should be about 1 ,500 pounds). The crews were allowed to apply “wiggle 
room” to the counts; that is, plus/minus two passengers or 10 bags did not require recalculating 
the weights. 


In contrast, under this airline’s revised procedures, the “wiggle room” was eliminated and a new 
calculation is now required whenever there are any load changes. The operations agents now enter 
the counts/weights reported by the ramp personnel into a computer input screen, producing a 
printed “loading schedule” for which the computer performs all math previously done manually. 
This program includes gross error-checking capable of catching some input errors, such as a cargo 
weight of 50,000 pounds that far exceeds the load limits of the aircraft. The load schedule is taken 
to the cockpit and handed to the crew. The form includes breakdowns for passenger, baggage, cargo 
and fuel weights, as well as the ZFW and GTOW. The pilots use the printed load schedule to enter 
both ZFW and GTOW into the laptop performance computer. The difference between these two 
weights should roughly match the fuel onboard. 

4.1.3 Flight Deck Data Entry 

At the regional turboprop operator the pilots transfer the performance data to the FMS by reading 
each datum off the handheld computer screen and typing it into the FMS CDU. The captain does 
the entries to the handheld computer then reads the values from its screen and the first officer does 
the FMS entries. 

At one of the large worldwide passenger carriers, three ACARS uplinks of performance data 
normally occur prior to takeoff. First is a planned weight manifest. The data on this manifest are 
discussed by the crew while still at the gate. They enter the planned weights in the FMS and use the 
speed card on the back of the checklist to look up and enter V-speeds. Second is a performance data 
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sheet, received before pushback, that reflects updated weights, usually close to final weights. Third 
is the final weight manifest, normally received during taxi. Pilots are not allowed to take off 
without it. This document provides the ZFW and ZFW CG, both of which are entered in the FMS. 
The final manifest also provides GTOW, passenger counts by zone, total souls on board, and the 
weight change from the forecast manifest to the final manifest. 

At another large worldwide passenger carrier, the performance data and V-speeds in most cases are 
uplinked directly to the FMS via ACARS. The pilots are required to accept the data uplink but there 
is no formal procedure for checking the uplink against the weight manifest or the planned data on 
the dispatch release. In some cases the uplink is not implemented and the pilots must manually 
enter data into the FMS using the printed weight manifest as a source. The data entry may be 
performed by either pilot. The other pilot is required to review the FMS entry for completeness but 
there is no formal cross-check or comparison between the data in the FMS and that on the weight 
manifest or dispatch release. 

4.1.4 Errors 

One of the large worldwide passenger carriers had been experiencing problems with pilots 
sometimes taking off without having received the final weights. When this happened the pilots 
realized the error when the final manifest was printed out after takeoff. The mitigation implemented 
for this problem was to change the Before Takeoff checklist so the first officer was required to read 
the weight change number (forecast vs. final) out loud. This number was only available from the 
final weight manifest so it facilitated trapping the absence of the final weights. This eliminated 
almost all of the incidents of taking off without final weights. The few that remain have to do with 
quirky issues such as the crew doing a gate return to deplane a passenger and then forgetting to 
report the change in passenger count and request a new final manifest. 

The problem of receiving revised final weights after takeoff used to occur more frequently before 
the company implemented internal controls in the central load planning system that do not allow a 
flight to be closed out without the final weight inputs (see Error Trapping, below). The current 
central load process also does not require any manual entries but instead drives directly from the 
scanned baggage, cargo, and passenger count inputs. 

A senior load-planning manager at this airline noted that errors often happen during irregular 
operations. He also stated, “Process errors can just as easily cause a 20,000 pound error as a 10 
pound error.” 

At one of the large passenger carriers, the most common error reported in a previously used load 
control system (which had involved agents manually adding the weight components to obtain 
GTOW) was a “10,000 pound fuel error.” This was a math error. It has been eliminated in the new 
system by having the computer do the computations. 

Another problem area of the previous system occurred when operations agents tried to work ahead 
by entering the planned or anticipated values for the weight components in order to pre-check for 
weight-limited flights. Sometimes they would then forget that the numbers in the records were 
planned values and didn’t replace them with the final numbers. In the new, current system, the 
software automatically zeroes out any previous inputs when the final weights are being prepared. 
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A captain at this airline related a personal experience: One day after reviewing the load schedule he 
had a feeling of “something’s not right.” He was flying an aircraft type variant that was relatively 
new to him so he was not accustomed to the normal performance data values for that type. During 
rotation, with the first officer flying, the aircraft rotated but did not lift off. Fortunately, the first 
officer froze the pitch attitude instead of continuing rotation into a possible tailstrike or angle-of- 
attack-prevented liftoff. Eventually the aircraft lifted off and climbed. Shortly thereafter the crew 
received a message that “the operations agent wants to speak with you.” Then they were told to 
change their passenger weight to a greater number. It was a 25,000 pound error. 

At this airline under the revised, current load control system, the pilots still do not have access to 
the raw counts and values from the ramp, gate, and fuelers (e.g., they do not get a fuel slip). The 
main vulnerability of the current system continues to be the quality of the load schedule that is 
prepared from the raw data by station operations, which still depends on accurate entries by the 
agents, transmittal of information from ramp agents, through supervisors, to operations agents. 
Handwriting is still involved on the ramp and miswriting or misreading an entry is possible. 

The planned performance weights are provided to the operations agents and flight crews through 
the dispatch release. The company procedure requires that operations agents compare the planned 
and actual weights and if the difference exceeds 5,000 pounds the operations agent is supposed to 
contact dispatch to obtain a new fuel burn for the final weight and to provide this number to the 
crew. The reliability of executing this procedure depends on the conscientiousness of the operations 
agent. They are supposed to take action on a 5,000 pound discrepancy regardless of whether the 
final weight is less than, or greater than, the planned weight. It is not clear whether an aircraft 
loaded to significantly less than its planned weight would reliably prompt review and resolution by 
either operations or dispatch, which leaves the possibility that an apparent underload might actually 
result from a performance data error. 

4. 1.5 Error Trapping 

At the regional turboprop operator, as part of the “cargo planning” function that provides pilots 
with the baggage and cargo counts/weights, one agent cross-checks his work against that of another 
and both sign the form to take responsibility. This cross-check was implemented after previous 
events involving errors. The cross-check and “two-signature” procedure improved the situation. 

The two pilots cross-check the output of the handheld computer entries against the entries made in 
the FMS. This particular FMS model is not capable of internally generating V-speeds that 
potentially could be compared with the ones calculated on the handheld computer and manually 
entered in the FMS. • 

The captain receives a load planning sheet with the anticipated passenger, baggage, and cargo loads 
about 30 minutes before departure to use for planning the fuel; however, for the most part there is 
no procedure to compare these anticipated values with the final actual values later in the process— 
which might help catch errors in the final numbers. However, a cross-check is performed with the 
cargo/baggage weight subcategories; about 10 minutes prior to pushback a ramp agent provides the 
captain an updated cargo load value which is mainly done to account for last-minute changes in 
baggage, such as gate-checked carry-ons. The captain compares this value with the one that was 
previously entered in the handheld computer from the load planning sheet. So there is an 
opportunity to compare the planned and actual weights for the cargo/baggage component of load. 
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We did not obtain information about this airline’s procedures for detecting and resolving 
differences between planned and actual total load. 

At one of the large worldwide passenger carriers, the lookup of data on the speed card (based on 
preliminary weights received from ACARS) is specified to be done independently by the captain 
and first officer. The first officer looks up and enters the data into the FMS and the captain then 
verifies, including an independent lookup on the speed card. 

At this airline there is a check and verify procedure for entries in the FMS. At the gate, the first 
officer enters the preliminary data from the printed forecast weight manifest and performance 
sheets. During taxi-out when the final weight manifest is received the first officer states “I’m going 
head-down” and then makes the required adjustments in the FMS. Then the captain verifies by 
cross-checking the entries shown on the primary flight display (PFD) against those in the FMS (this 
cross-check is capable of alerting the crew to a subset of errors, such as changing the departure 
runway without entering the associated revised performance data for the new runway. However, the 
captain does not cross-check the data in the FMS against the data on the final weight manifest, 
which would be a more comprehensive cross-check capable of alerting the pilots to other errors. 

Also, at this airline pilots are supposed to review a weight change and, if it exceeds a stated value, 
call dispatch for a new flight plan or re-release. The call to dispatch is required for being both over 
and under the forecast weight. But if the final weight is less than the forecast weight, the dispatcher 
will usually just say “You’re good to go.” There is no requirement to resolve the reason for the 
difference between the forecast and the final weight. 

This airline eliminated the manual passenger count by the flight attendants about five years ago in 
favor of relying on the gate scanning process. The gate agents are responsible for reconciling the 
booked vs. scanned passenger counts as part of the closeout process. An audit during this change 
process showed that the gate counts were more accurate than the flight attendant counts. 

Pilots enter the fuel on board as displayed on the fuel gauges into the FMS. The direct entry of fuel 
by the pilots is designed to catch a fueling error in which the fuel on the aircraft does not match that 
shown on the final weight document. 

This airline recently implemented a robust system to catch errors in the loading and data calculation 
functions . The great majority of the errors caught by the system appeared to be too small to pose 
appreciable risk and were related to inaccurate passenger counts. In these, the closeout occurred so 
the flight could be released for departure, generating the final weight sheet in the cockpit. Then, an 
agent manually re-opened the flight to correct the passenger count and this generated another 
closeout and revised final performance data. The automated error-trapping system is designed to 
notify the crew that their numbers are invalid and to expect and wait for revised numbers if the 
flight is re-opened for correction before the flight has taxied less than 50% of the planned taxi time; 
this would not be classified as an error and would be counted among the caught errors. However, to 
avoid the risks of generating a distracting message during takeoff roll, if more than 50% of the taxi 
is completed the system does not directly alert the crew but routes the “invalid weights” message to 
the flight’s dispatcher. When the weights have been re-finalized, if the change is more than a half 
percent of the previous TOW, the new numbers are sent to the cockpit via ACARS. If less than that 
percentage change, the new numbers are sent to the dispatcher who can review whether the change 
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is significant with respect to limitations. In any case, if the flight takes off with the uncorrected 
performance data this is flagged as an error by the system . 

This system requires supervisors to investigate each error and if the error exceeds the limit value to 
document the findings. As an example, a 60-pound cargo error was found to involve the ramp 
adding two bags after closeout. These supervisory investigations occur after the flight has operated 
so they cannot trap errors but may help prevent recurrence of error. 

These errors are being flagged because the airline is reconciling the data, mostly before departure 
but sometimes, in error, after departure. In comparison, before adopting this automation procedure 
the airline did not attempt to reconcile the loads until after departure on a regular basis. One person 
we talked with estimated that the typical discrepancy found after departure before the new 
procedure was adopted was 3,000 pounds. These errors were never reported because of a harsh 
reporting culture— one had to report each error to the vice president. It was suggested to us that 
other airlines that do not have an automated system such as this one are sending out flights loaded 
incorrectly without ever knowing about the errors. 

At one of the large passenger carriers a large discrepancy between the planned ZFW and actual 
ZFW will be flagged by the laptop by displaying an error message on the screen. However, the 
comparison is between the value that the dispatcher used for fuel/altitude planning and the actual 
weights. The dispatcher’s planned weight value comes from an early estimate of the loads and there 
is no explicit coordination between the dispatch and the load planning functions for updating these 
estimates so the laptop’s built-in comparison is not particularly good for catching loading or 
calculation errors. 

The laptop automatically checks that the laptop-generated ZFW is not more than 1 ,000 pounds 
greater than the dispatcher estimated ZFW and flags any discrepancies. If the laptop flags the actual 
ZFW more than 1 ,000 pounds greater than the estimated value, then the crew calls dispatch to 
confirm that the fuel load is adequate for the increased burn resulting from the heavier gross weight. 

One captain personally compares the planned vs. final numbers and if there is a big difference he 
makes sure that he understands why (fewer passengers, unanticipated cargo, etc.). However, there is 
no requirement for the crew to compare or think about it beyond the laptop alert. In one instance 
this captain received a fuel burn value that was 8,000 pounds instead of the 16,000 pounds he 
would normally expect for the trip being flown. This discrepancy took a lot of work to resolve; it 
turned out to be a gross performance data error. 

At another airline that this captain flew for previously, on one occasion the passenger count input 
by the crew was zero (or left blank) and as a result the flight had to do an air turnback at the 
midpoint of an ocean crossing due to inadequate fuel reserves to complete the crossing. He related 
that if this error had occurred with his current airline’s performance data system the laptop’s 
automated error trapping function would generate a pop-up box asking the crew whether they were 
sure about the zero value for passengers. 

This airline uses a cut-off time to stop accepting cargo for a flight and this is effective in controlling 
the trickle-out of last minute cargo to the ramp. If accepted, cargo is not actually loaded on the 
aircraft, procedurally it must be delisted from the manifest. If it is not delisted prior to departure, 
this error can be caught if the lead agent reports to the captain that a listed item was not loaded. 
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Also, it may be noticed if an unloaded cart is noticed sitting on the ramp and “someone” notifies 
station operations. 

If a weight is entered incorrectly, operations personnel reviewing the load can notice if a final 
weight (e.g., cargo, passenger, or baggage weight) does not match the load plan. They are then 
supposed to ask whether the captain was notified. There is also a reporting mechanism in which 
discrepancies are supposed to be investigated. But all of this happens after flight departure or 
even after arrival. There is no procedural comparison of the final load numbers to the load plan 
that takes place prior to departure. There is no procedural reconciliation of any differences or 
apparent discrepancies. 

A senior cargo operations manager stated that some kind of pre-departure review of the final load 
against the plan and/or reconciliation would be useful. The best place to do this would be in the 
cockpit. Right now the flight crew is not given the load plan so they do not see the planned 
passenger, baggage, and cargo weights. Accordingly, they are inhibited from checking, questioning, 
and initiating reconciliation. Giving them the load plan would be an improvement. 

At another large passenger carrier, after the first officer enters the data in the laptop performance 
computer, the pilots perform a series of quality control checks that have been specified in the 
company’s SOPs. The captain checks specific items on the load schedule against what is displayed 
on the laptop, including the aircraft number/type, and verifies that the components of the ZFW 
shown on the load schedule are not grossly in error (e.g., the passenger/bag weights are not zero). 
Then, during the Before Push checklist, the captain and first officer systematically step through the 
entries on the laptop and FMS (the entries have been formatted to look alike on both devices) to 
verify that the first officer transferred the data into the FMS correctly. 

One example of an error trapped by this system occurred when an operations agent forgot to 
enter any cargo weight. This was caught by the captain who saw zero for the cargo entry on the 
load schedule. 

The pilots also cross-check that the sequence number of the release matches that of the load 
schedule, signifying that the two are based on the same information. This catches potential errors in 
which either document may be revised without revising the other. As another cross-check, this 
airline’s procedures require the crew to obtain a flight attendant customer count to check against the 
passenger count that the gate agents provide to the pilots. 

4.1.6 Future Technologies and Procedures 

One senior load planning manager we talked with would like to see items scanned as they actually 
enter the aircraft (using radio-frequency idenfification technology for the cargo and baggage). He 
would also like to see a fuel planning system that sends the fuel order directly to the fuel truck, 
perhaps even controlling the fuel valves automatically to avoid over-fueling (this is more of a 
cost/efficiency item than a safety item). 

He suggested that a flight planning system which accepts weight/balance inputs from the final 
weight documents and quickly recalculates performance would allow for more accurate planning. 
Currently, flights are planned early in the process, before the final weights are known, and as a 
result they have to include a buffer of up to several thousand pounds to account for weight changes 
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to the final. Updating the flight plans with the final weights would be more efficient for fuel and 
altitude planning. 

A senior cargo operations manager at another airline said that he would welcome a way to scan 
cargo both as it leaves the warehouse and as it is loaded on the aircraft if it could be done in a cost- 
effective way. “The less manual handling the better.” There would also be security and loss-control 
benefits. He also said that an aircraft that could weigh itself and automatically cross-check the 
weight and balance calculations would be a very welcome improvement. 

4.2 Summary of Process Steps in Three Variants 

Based on these discussions with airline personnel, we developed a flow diagram of three variants of 
the performance data processes that are in current use by the air carrier industry (Figures 1-3). 
These three variants are not exhaustive of all of the performance processes that are in use but rather 
they are representative of some of the commonly existing combinations of procedures and 
technologies. We also used the information from our discussions with airline personnel to guide us 
in defining the process step, actor, and error type variables for our ASRS case analysis as we 
discussed in the Method section. 
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Figure 1 . Central load planning with station operations model. 
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Figure 2. Central load planning without station operations model. 
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Figure 3. Flight deck load planning model. 


4.2.1 ASRS Case Analysis 

Ninety-eight of the 100 reports selected for detailed analysis were submitted by airline pilots 
reporting on a specific flight segment that they flew and two reports were from dispatchers. This is 
consistent with the nature of the ASRS database in which the great majority of reports come from 
pilots who receive some degree of immunity from FAA enforcement action by submitting reports 
of incidents compromising safety. One hundred and twelve distinct errors were reported among 
these 100 flights. 

The reports provided adequate information to identify the type of operation for 97 flights, of which 
84 were passenger flights (Table 1). 
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Table 1 . Operation Type 



Frequency 

Passenger 

84 

Cargo 

12 

Other repositioning 

1 

Total known 

97 

Total unknown 

3 

Total 

100 


Jet aircraft were operated in 91 flights. More than 13 aircraft types were involved (Appendix A); 
however, we do not have data on the relative frequency of operation of these aircraft types, which 
would be required to calculate relative likelihood of error among aircraft types. 

4.2.2 Locus of Error Reported 

Sixty-nine of the 112 reported errors were made by ground personnel performing functions external 
to the flight deck while the other 43 errors were made by flight personnel performing cockpit 
duties. Ground personnel errors were distributed among central load planning, station operations, 
and ramp/gate, with the latter being reported most frequently (Table 2). 


Table 2. Locus of Error External to Flight Crew 



Frequency 

Percent of All Errors 

Central load planning 

12 

17.4 

Station operations 

10 

14.5 

Ramp or gate 

18 

26.1 

Total known 

40 

58.0 

Total unknown 

29 

42.0 

Total 

69 

100.0 


Gate and ramp personnel error: 

“ ...ramp had loaded a cart of freight weighing 1 .700 pounds 
instead of a cart of freight weighing only 300 pounds.'’ 

ACN 668967 


This subcategory of personnel was not available for 29 of the 69 errors made by ground personnel. 
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Error made by unknown ground person: 

“Just after takeoff, the Captain told me that it felt like he 
almost over-rotated and that the back pressure at takeoff was 
extremely light. About 10 minutes after takeoff, 1 noticed. ..a 
new final weight manifest from operations sent to us 5 
minutes after we already departed! New zero fuel 
weight. ..and new trim setting 

ACN 534159 


In this example, the report did not provide information about which ground person made the error 
that led to incorrect weight and trim values provided the flight crew before gate departure and 
corrected only after the flight had been exposed to risk during takeoff. Although the reporter cited 
“operations” as the party from whom the incorrect information was received, this pilot did not 
specify the actual source of the error (which may have been, for example, a miscount by a ramp 
agent that entered into the calculations made by the station operations personnel). 

4.2.3 Process Steps, Actors, and Types of Errors 

As described in the Method section, we developed a list of steps involved in the performance data 
process, the actors involved (depending on the way each individual airline established its processes 
and the technologies employed), and the types of error that might in principle be made in these 
process steps. These are depicted in Table 3. 
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Table 3. Error Process Steps, Actors, and Types 


Process Step 

Actor: Error 

Subtotal: 

Ground 

Locus 

Subtotal: 
Flight Deck 
Locus 

Forecast load limitations 
(weight restrictions) 
(subtotal=0) 

Load planning: Failure to produce forecast 
for weight restriction. 

0 

0 

Load planning: Failure to disseminate 
weight restriction. 

0 

0 

Revise forecasts based 
on changes in weather, 
tempeature, runway, 
fuel requirements 
(subtotal=0) 

Load planning: Failure to adjust for 
changed conditions 

0 

0 

Load planning: Failure to disseminate 
changes. 

0 

0 

Obtain actual cargo 

weights 

(subtotal=15) 

Ramp: Weighing error. 

0 

0 

Cargo department: Incorrect transmittal of 
waybill data to load control or ramp. 

1 

0 

Ramp/cargo: Data entry by omission of 
scanning. 

1 

0 

Ramp/cargo: Counting error. 

1 

0 

Ramp/cargo: Data entry with incorrect 
weight value. 

6 

0 

Ramp: Failure to load/offload containers. 

2 

0 

Ramp/cargo: Data entry by erroneous 
container position. 

1 

0 

Obtain actual passenger 

count/weight 

(subtotal=3) 

Gate: Data entry error by failure to enter or 
scan boarding passengers. 

0 

0 

Gate: Miscount of passengers. 

1 

0 

Gate/operations: Math error with total 
count or distribution. 

0 

0 

Gate/operations: Data entry error with 
passenger total or distribtuin. 

1 

0 

Load planning: Data entry or math error. 

0 

0 

Gate/operations/load planning: Late or 
omitted transmital of data to operations, 
load planning, or pilots. 

1 

0 


continued on next page 
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Table 3. Error Process Steps, Actors, and Types (continued) 


Process Step 

Actor : Error 

Subtotal : 
Ground 
Locus 

Subtotal: 
Flight Deck 
Locus 

Calculate 

weight/balance 

(subtotal=20) 

Operations/load planning/pilots: Data entry 
error. 

7 

4 

Operations/load planning/pilots: Math 
error. 

2 

6 

Pilots: Failure to enter data in ACARS or 
laptop. 

0 

0 

Crew: Failure to clear previous flight data 
from ACARS or laptop. 

0 

0 

Gate/operations/load planning: Late or 
omitted transmittal of data to 
perations/load planning/pilots. 

1 

0 

Verify weight/balance 
agains performance 
limits 

(subtotal=13) 

Opeations/load planning/pilots: Use of 
incorrect runway, temperature, wind, or 
weights for inputs. 

3 

1 

Operations/load planning/pilots: Data entry 
error for runway, temperature, wind, or 
weights. 

0 

0 

Operations/load planning/pilots: Failure to 
update for changes in reunway, 
temperature, wind, or weights. 

0 

5 

Operations/load planning/pilots: Failure to 
check limits. 

0 

4 

Operations/load planning/pilots: Failure to 
flag and correct violated limitation after 
checking. 

0 

0 

Calculate V-speeds, trim 
settings, flap setting 
(subtotal=3) 

Operations/load planning/pilots: Use of 
wrong runway, temperature, wind, or 
weights for inputs. 

2 

1 

Operations/load planning/pilots: Data entry 
error for runway, temperature, wind, or 
weights. 

0 

0 

Operatioins/load planning/pilots: Fail to 
update for changes in runway, 
temperature, wind, or weight. 

0 

0 


continued on next page 
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Table 3. Error Process Steps, Actors, and Types (continued) 


Process Step 

Actor: Error 

Subtotal: 

Ground 

Locus 

Subtotal: 
Flight Deck 
Locus 

Transmit weight/ 
balance, performance 
speeds, trim settings to 
flight deck 
(subtotal=5) 

Operations/load planning/pilots: Error in 
rreading, recording weight/speed/trim 
data from source. 

0 

i 

Operations/load planning/pilots: Error in 
re-inputting, recording 
weight/speed/trim data from source 

0 

i 

Pilots: Failure to request data/uplink via 
ACARS 

0 

0 

Pilots: Failure to ntice that data not 
received prior to departure 

0 

3 

Enter weights into FMS 
(subtotal=6) 

Uplink data error (no person). 

1 

1 

Pilots: Error reading received/uplinked 
data. 

0 

1 

Pilots: Failure to input final data. 

0 

0 

Pilots: Failure to indentify uplink error. 

0 

1 

Pilots: Data entry error. 

0 

1 

Pilots: Table lookup error. 

0 

1 

Input V-speeds, trim 
settings into FMS 
(subtotal=10) 

Uplink data error (no person). 

0 

0 

Pilots: Error reading received/uplinked 
data. 

0 

0 

Pilots: Failure to input final data. 

0 

0 

Pilots: Failure to identify uplink error. 

0 

1 

Pilots: Data entry error. 

0 

0 

Pilots: Table lookup error. 

0 

0 

Set bugs 
(subtotal=l) 

Pilots: Failure to set bugs. 

0 

0 

Pilots: Error in setting bugs. 

0 

0 

Pilots: Cross-check error. 

0 

1 

Set trim 
(subtotal 1) 

Pilots: Data entry by failure to set trim. 

0 

1 

Pilots: Error in settring trim. 

0 

1 

Pilots: Cross-check error. 

0 

0 

Set flaps 
(subtotal=5) 

Pilots: Data entry by failure to set flaps. 

0 

1 

Pilots: Data entry by erroneous flap setting. 

0 

4 

Pilots: Cross-check error. 

0 

0 

Total 
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Seventy-three of the reports contained enough information for us to identify the functional step in 
which an error was made in the process of generating, transmitting, and entering performance data; 
identify the actor (ramp/gate, station operations, load planning/control, or flight crew) making the 
error; and characterize the type of error. In Table 3 we populate the list of possible errors with the 
actual errors reported, the process steps in which the errors occurred, and the actors committing 
those errors. 

The process steps most frequently reported to have errors were obtaining actual cargo weights (15 
errors), calculating weight and balance (20 errors), and verifying the weight and balance with respect 
to aircraft performance or limitations (13 errors). Note that these data do not reveal the relative 
frequency with which these errors actually occur because the probabilities of different error types 
being reported is completely unknown. Here are examples from each of these three categories: 

Obtaining Actual Cargo Weights. The 15 errors in this step in the process were distributed among 9 
distinct types of error. The most frequent category was errors made by ramp/cargo personnel as they 
entered the weight data (6 errors). A seventh entry error involved omitting the scanning of cargo. 

Among these 7 data entry errors, we considered that several different functions might have been 
involved, depending on the various processes and technologies that the air carriers in our sample 
used for transmitting weight data from the loading ramp, for example: 

• Incorrectly marking a load sheet to be passed to the flight deck. 

• Omitting or not making computer keyboard entries later to be printed in the 
operations office. 

• Not scanning cargo waybills. 

• Scanning containers previously marked with incorrect weights, with the scanned 
information then being transmitted and used for calculations without further 
human input by a central load planning computer. 

However, these details were not available in the ASRS case narratives for the cargo data entry 
errors. Here is an example of one of the error narratives, showing the level of detail that was typical 
for an error made by ground personnel as reported by a pilot: 


Obtaining cargo weights error: 

“The ramp had loaded extra bags and had not made the 
operations agent aware of the addition. ..An error of this type 
has definite potential to compromise safety.” 


ACN 594017 


Calculating Weight and Balance. Among the 20 errors at this step in the process, the most common 
types of error were data entry errors made by ground personnel (7 errors) or pilots (4 errors) and 
math errors made by ground personnel (2 errors) or pilots (6 errors). 
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Data entry error by ground personnel: 

“ The operations agent handed me the load sheet and I began to 
make the appropriate entries in the FMC and [laptop 
performance computer] ...We noticed and commented that we 
were really light and were going to take off like a rocket. ..Once 
in the air , we received a radio call from operations telling us to 
revise our takeoff weight... The correct weight was actually 
19 >000 pounds heavier. We then realized the numbers added up 
correctly but the passenger weight was extremely low... The 
operations agent had entered 33 passengers into the computer 
versus the 133 passengers that we actually had... The plane took 
off fine, although the captain said it felt a little mushy on liftoff. 
But had we lost an engine on takeoff at that heavy weight and at 
that altitude , we may not have been able to stay airborne. ” 

ACN 669643 


Data entry error by flight crew: 

“In his haste, the first officer entered the adjusted weight unit 
for 25 passengers in zone 2 instead of the 24 we actually had 
on board. yt 

ACN 675274 


Math error by ground personnel: 

“At pushback, I noticed that the takeoff weight appeared to be 
very light for a B737-700...0n takeoff, the aircraft felt heavy at 
the computed speeds > so / rotated and allowed the aircraft to 
fly off at the speed it needed. This appeared to be about 10 
knots faster than computed. ..The first officer double checked 
the load manifest and found that there was a 10,000 pound 
error on the zero fuel weight. I entered the correct zero fuel 
weight into the flight management computer. The first officer 
radioed back to [the departure station ] to check their 
paperwork. The coordinator stated that the operations agent 
had already found and corrected her mistake. yy 

ACN 585778 


Math error by flight crew: 

“We were running late. I was rushing through paperwork. On 
the load manifest, I made a calculation error and wrote in the 
wrong landing weight. '* 

ACN 479900 
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Verifying Weight/Balance Against Performance Limits. Among the 13 errors at this step in the 
process were those that involved entering the wrong data for weights, winds, runway, or 
temperature, etc. (4 errors of which 3 were made by ground personnel), not updating for changes in 
these parameters (5 errors, all by pilots), and not checking calculated performance against 
performance limits (4 errors, all by pilots). 


Entering wrong data: 

“The takeoff and performance data received from our company load 
planners specifically contained the statement advising us to ‘ expect a 
departure on Runway 34R,from intersection O' ...It is customary that 
when an intersection takeoff is defined... there is also a corresponding 
runway takeoff analysis, based on the specific intersection takeoff 
point... indicating maximum takeoff weights for the runway intersection 
takeoff point. ..but not in this case!. ..We had only been issued a full 
length runway analysis... I learned that although the air carrier uses a 
central load planning system the local stations have some authority 
over selected weight and balance entries. ..Simply put, the station told 
us to expect one thing , but gave us information for another , a 
potentially fatal error in this case. ..There are other problem areas 
too... For example, if the runways are wet with standing water , and I ask 
dispatch to show [performance data for] a contaminated runway, the 
reply I get is that they cannot , because the station is not reporting it!' 1 

ACN 547346 


Not updating for changes: 

“We completed our load manifest paperwork and were closing the 
main cabin door for pushback when ramp personnel advised us that we 
were going to have more passengers. The new passengers trickled out 7 
and 2 at a time... we did not realize that extra passengers put us 
overweight. We did not discover this error until cruise when I started to 
prepare the landing data for our approach. 11 

ACN 6675 14 

Not checking against limits: 

“While preparing the weight and balance form for our flight ...I failed 
to recognize that we would be taking off over our landing structural 
weight. This is. ..calculated by adding the planned fuel burn-off to the 
landing structural weight [limit]. .After we pushed away from the gate , 
we found the error, however , we did not exceed any aircraft limitations 
by running the APU for the entire flight, flying at a lower altitude than 
originally planned and using flaps 9 degrees earlier than normal... 
Contributing factors include the rush to push the flight on time, having 
more passengers than originally expected, and the fact that our weigh t 
was less than [maximum] aircraft takeoff structural weight (easier for 
me to overlook the fact that we were over planned landing. ..limit).' 1 

ACN 573981 
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Entering Data in the FMS. One of the main industry concerns leading us to conduct this study was 
flight crews inadvertently entering wrong data into the FMS. Five errors were reported that 
involved the process of entering data in the FMS; however, only one of these was a pure keyboard 
entry error, while the other four resulted directly from an error that the pilots had made reading, 
manipulating, or checking the data as they made the keyboard entries (looking up information on 
the wrong reference card, misreading data that they had received, not identifying an error in the data 
that had been uplinked to the flight deck). These errors are summarized in Table 4. 


Table 4. Errors Involving FMS Data Entry (n=5). 


ACN 

Description 

Contributor(s) 

530341 

Flight crew entered incorrect fuel 
weight into FMS despite correct 
weight displayed on fuel gauges 
(checked gauge but saw the expected 
value rather than actual value). 

Fueler underfueled aircraft by 3,000 pounds 
but provided pilots with the planned 
(incorrect) amount on the fuel form. Pilot 
verifying fuel by looking at gauge then 
“saw” the expected value— not the one that 
was really in the tank and on the gauge. 

615939 

Given a runway change during taxi- 
out, flight crew entered the incorrect 
“assumed temperature” for reduced- 
power into FMS, resulting in long 
takeoff roll. 

Company paperwork provided temperature 
in degrees Farenheit but the FMS required 
Celsius for input. 

632164 

First officer mistakenly entered ZFW 
in the FMS input box for GTOW, 
resulting in poor performance in 
takeoff and cruise. 

Pilots were new to the aircraft type, so not 
familiar with typical weights and speeds. 

710246 

Input planned weights into the FMS 
instead of final weights during the 
Before Takeoff Checklist. 

Ground personnel did not send final weights 
prior to or during taxi-out and flight crew 
did not notice. 

790465 

Crew input weights/speeds for 
100,000 pounds less than actual 
weight into the FMS, resulting in poor 
takeoff and climb performance. 

Crew mistakenly used a printed speed card 
for 270,000 rather than the aircraft’s actual 
weight of 370,000 pounds as their reference 
source for FMS inputs. 
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Setting the Flaps. Although it was not reported as frequently, setting the flaps to the wrong position 
(4 instances) had very serious consequences. 


Flap setting error: 

“1 had run the numbers in the [latptop performance computer] 
and it required a flaps 15 degrees [setting for takeoff], best 
case gave only 21 feet of stopping distance [in the event of 
rejected takeoff]. We briefed the flaps 15 deg takeoff, but with 
my mind on other things, when the captain called for [the 
usual] flaps 5 degrees (habit patterns ) after engine start, 1 
didn't catch it and tracked the flaps to 5 degrees. Neither of us 
caught the mistake. On takeoff roll approaching the 2,000-feet 
remaining mark, I saw the captain pulling back on the yoke. 

We had set trim at 3.5 units and it was a long pull. That was 
when it hit me that we hadn't set the flaps to 15 degrees as 
required by the [laptop performance computer] . We cleared 
the fence at the departure end and the rest of the climbout was 
uneventful. When we ran the numbers on the way to our next 
city, we found we were over 4,000 pounds too heavy for a flaps 
5 degree takeoff. ” 

ACN 625930 


Our ASRS cases also included a single instance of the extremely serious error of not extending the 
flaps at all. This occurred when the pilots omitted the entire Before Takeoff checklist, including the 
steps of both setting and checking the flaps, and it was caught by activation of the aircraft’s takeoff 
configuration warning system. 

4.2.4 Fuel Load Errors 

Nine errors by ground personnel and pilots in loading, documenting, entering, and verifying fuel 
loads occurred, cutting across (and included in) the process step, actor, and error type results 
described in the previous section. Because airlines may use different procedures to account for the 
fuel load than they use for the payloads of passengers, cargo, and baggage, we reviewed the ASRS 
case sample for events specifically related to fuel (Table 5). 


46 


Table 5. Errors Involving Fuel Loading, Documentation, Entry, 
and Verification (n=9) 


ACN 

Description 

529324 

Ground personnel provided fuel weight value missing the 1 in the 100,000 column, 
resulting in 100,000 pound error and leading to tailstrike. 

804855 

Load manifest from ground personnel omitted trailing zero from fuel weight value, 
resulting in 100,000 pound error and speed decay in cruise. 

530341 

Fueler underfueled aircraft by 3,000 pounds but provided pilots with the planned 
(incorrect) amount on the fuel form. Pilot verifying fuel by looking at gauge then 
“saw” the expected value— not the one that was really in the tank and on the gauge. 

538960 

Load manifest from ground personnel missing trailing zero in 10,000 pound fuel 
weight, resulting in 9,000 pound error. 

605400 

Pilots did not properly account for ballast fuel, led to exceeded max ZFW limitation. 

703116 

Pilot made 10,000 pound math error while adding fuel weight to the ZFW (for 
entry into the FMS). 

582934 

For performance data calculations, pilot used fuel value that had been discussed 
earlier instead of the fuel load actually aboard the aircraft, 

587708 

Fueler mistakenly substituted fuel loads for two different tanks, resulting in 
incorrect CG calculation. 

779098 

Fueler misfueled the aircraft; pilot noticed the misfueling and intended to correct 
the situation but forgot to do so, resulting in nose-heavy takeoff. 


4.2.5 Laptop-Related Errors 

Based on the involvement of laptop performance computers in major accidents and incidents, we 
reviewed the ASRS case sample for laptop-related events. There were no events involving the 
specific errors that were causal to the Halifax and Melbourne accidents; i.e., data entry errors 
comprising failure to enter the new flight’s performance data leading to mistaken use of the 
previous flight’s data, and mistaken entry of the ZFW value into the GTOW field of the laptop. In 
one instance, a pilot entered a weight value from the wrong line of the load manifest into the laptop, 
obtaining an incorrect projected landing weight from the laptop that led to the flight departing 
overweight. In another, a pilot entered the incorrect variant of the aircraft type into the laptop, with 
no adverse consequence. In third ASRS case, the laptop equipment apparently malfunctioned (after 
being cold-soaked) and although the pilots entered the data correctly the laptop’s outputs were 
erroneous; these incorrect performance parameters were not caught by the pilots, resulting in 
uncommanded pitch-up and a high speed rejected takeoff (RTO). There were additional ASRS 
cases in which the pilots obtained incorrect counts and weights from earlier steps in the 
performance data process and then entered these into the laptop, but the laptop technology was not 
related to these errors or failure to catch them. 
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4.2.6 Error Trapping 

Only 20 of the 112 errors were trapped before becoming consequential. This datum may not reflect 
the actual effectiveness of error trapping in the population of all flights; trapped errors are probably 
far less likely to be reported than errors that become consequential, but, on the other hand, errors 
that never became apparent to the pilots (and thus could not have become the subjects of ASRS 
reports) are probably less likely to be trapped than those known to the crews. (An example of the 
latter would be a calculation error made by ground personnel that the pilots do not notice.) These 
two biases are in opposite directions and the net effect cannot be determined. 

Error Trapping Failures. An error was coded as one of the 92 that was not trapped if it was not 
identified, caught, and corrected before the flight was exposed to risk. For example, a baggage 
counting error that was identified by someone on the ground might be considered to have been 
trapped by the person catching the error. However, if revised performance data were not passed to 
the flight crew before departure then the flight would still have taken off with the incorrect data and 
therefore been exposed to possible tailstrike, failure to lift off, or inadequate climb performance 
over obstacles. Consequently, this error cannot be considered to have been successfully trapped. 

Overall, the ASRS reports contained little information about the specific error-trapping procedures 
used by the airlines, especially in ground functions. The reports also contained little information 
about why errors were not trapped, especially in the ground functions. 

However, in 12 of the 100 flights the pilot making the report provided adequate information not 
only about the performance data error that occurred but also about why the error was not caught. In 
these 12 reports we were able to identify breakdowns in verifying data and in noticing, reconciling, 
and correcting discrepancies and we coded these aspects as additional errors. These additional 
errors provide some insight into error trapping failures. The primary errors that were not trapped, 
and the reporter’s explanations of not trapping them, are summarized in Table 6. The insights 
provided by these reporters about their experiences with error trapping failure are evaluated in the 
Discussion section. 


48 


Table 6. Error-Trapping Failures Described by Reporters 


ACN 

Primary Performance Data Error 

Err or -Trapping Failure Description 

530341 

Fueler underfueled the aircraft by 3,000 
pounds, but entered the planned 
(greater) fuel amount on the fueling 
record given to the flight crew. 

Pilots looked at the fuel gauges to verify 
the fuel onboard but saw the expected 
value rather than the (lesser) actual value. 

710246 

Ground personnel did not send final 
weight data at the normal time during 
taxi-out. 

Running late and time-pressured by a 
quick takeoff clearance, pilots did not 
notice the absence of final weight data and 
took off without them (mistaking a 
weather printout for the final weight 
printout in the dark cockpit). 

675274 

First officer made a mistake with the 
weight and balance calculation. 

Captain did not catch the error while 
reviewing the data, attributed to being late 
and rushing. 

742390 

Ground personnel sent loading data for 
previous day’s flight. 

Pilots missed “red flags” of being 25,000 
pounds under planned weight, runway data 
being flagged as “preliminary,” and 
incorrect data on data printout header. 
Assumed that what came over the printer 
would be for their flight. Rushing and did 
not take the time to resolve the “red flags.” 

483680 

Load planning and dispatch sent 
incorrect weight and balance data 
allowing aircraft to be overloaded by 
10,000 pounds. 

Pilot’s math error (affected by rushing for 
on-time) prevented catching the original 
error until re-looking at the math during 
taxi-out. 

662092 

Confusion among load planning 
personnel and flight crew during an 
irregular operation led to ground 
personnel not providing timely final 
weight data. 

Given the same confusion, flight crew 
departed without final weight data under 
the mistaken impression they had obtained 
adequate data. 

779098 

Fueler neglected to add fuel to tail tank 
and load planning did not check planned 
against actual fuel distribution among 
tanks. 

Pilot noticed the discrepancy, intended to 
contact dispatch to resolve it, but was 
distracted and forgot. Aircraft was very 
nose-heavy on takeoff. 

793424 

Payload planning by ground personnel 
omitted passenger and cargo weights. 

Pilots noticed, but did not resolve, an 
automated warning on their final weight 
data that the flight was more than 10% 
over its planned weight, then experienced 
high fuel burn in cruise and had to divert to 
refuel. 


continued on next page 
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Table 6. Error-Trapping Failures Described by Reporters (continued) 


ACN 

Primary Performance Data Error 

Error-Trapping Failure Description 

481650 

Ground personnel provided performance 
data based on the wrong aircraft 
number. 

Rushing due to being late, pilots did not 
notice the error until cruise. Aircraft 
numbers looked similar and this error by 
ground personnel is unusual/unexpected. 

537000 

Ground personnel omitted the jumpseat 
occupant from the performance data 
calculations. 

Influenced by the gate agent’s statement 
that the passenger count was “exactly 
right,” the pilot did not catch this omission 
(which could have been identified by 
review of the paperwork). 

726238 

Gate agent provided incorrect passenger 
count (5 rather than 45) for pilots to use 
for performance data calculations. 

Airline’s procedure also included a 
passenger count by the flight attendants but 
the pilot did not verify the gate count 
against the flight attendant count. 

585778 

Station operations agent made a 10,000 
pound math error in adding the 
passenger, baggage, and cargo weight 
components to the aircraft’s empty 
weight to obtain ZFW. 

Pilot had checked some of the agent’s math 
adding fuel weight to the ZFW to obtain 
takeoff gross weight but did not check the 
components of ZFW until noticing 
degraded takeoff performance. 


Effective Error Trapping. Of the 20 errors that were trapped, 18 were trapped by persons (16 by 
flight crew and 2 by station operations personnel) and the remaining two were trapped by systems 
or automation. 


Effective error trapping by flight crew: 

“Aircraft fuel load called for all main tanks full, plus upper 
and lower aux tanks full, plus 12,400 pounds in forward aux 
and 6,200 pounds in tail tank. Fuel slip and company weight 
and balance showed the proper fuel load, but fueler put 6,200 
pounds in forward aux and 12,400 pounds in tail tank. We 
were right at maximum structural takeoff weight. Had we not 
noticed the error, possible tail strike on takeoff or worse if 
center of gravity had been aft of controllable limits.” 

ACN 587708 
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Effective error trapping by technological systems: 

“ Due to this bustle, we never accomplished the Before Takeoff 
checklist. When the captain (pilot flying) pushed the thrust 
levers forward, we got the configuration warning. I put the 
flaps to our takeoff setting and when they reached their 
position, we continued our takeoff. At rotation, much to my 
chagrin, I realized that we indeed forgot the checklist.” 

ACN 631420 

Thirteen of the 18 reports of errors trapped by personnel contained enough information to evaluate 
the role of procedures in trapping the error. Pilots were the ones performing the successful trapping 
all 13 of these errors. Only two of the 13 errors were trapped as a specific result of the pilots 
executing SOPs such as checklists and prescribed cross-checks. The other 1 1 errors were trapped by 
the pilots performing additional cross-checks on their own initiative and resolving suspicious or 
inconsistent performance data. This non-procedural error-trapping is exemplified by the following 
case of a pilot going beyond the SOPs to resolve a feeling of uncertainty after receiving unusual 
results from an ACARS-based performance data system that had evidently provided an incorrect 
uplink for technological reasons: 

Non-procedural error trapping by flight crew: 

“ [Passenger and baggage count] was entered into ACARS and 
an error response came back that the aircraft was 2.1 forward 
out of trim. 1 rechecked this because this was odd to have this 
result from a normal aircraft loading. ..I just could not believe 
this and I called dispatch. ..We agreed to use the center of 
gravity calculator and do the weight and balance by hand. This 
resulted in a center of gravity trim of 7.8, well within limits. ..We 
had similar issues with this ACARS’ results [on the next 
flight] ...that included a VI speed of -35. Now this is obviously 
an erroneous number, but what if. ..this ACARS had generated a 
VI of 122 and a VR of 124 instead of a silly number like -35. ..[a 
normal VI and VR would have been 145 and 146]. This could 
have generated takeoff numbers that could lead to an aircraft 
prematurely rotating and stalling. .Maintenance had us reset 
the ACARS circuit breaker and the [datalink communications 
radio] ...circuit breaker and the problem was resolved. 1 have 
flown this aircraft for years and the numbers coming out of the 
ACARS were not making sense.” 

ACN 777532 


This extra level of scrutiny and effort to resolve discrepancies, though not specifically mandated by 
the SOP, is an important safeguard that apparently draws upon pilots’ knowledge and prior 
experience to sense when computed performance data are out of reasonable bounds for the specific 
aircraft and operation. We examine the effectiveness and reliability of this kind of experience- 
based, ad-hoc error trapping in the Discussion section. 

Among the ASRS reports that met our selection criteria but were not randomly selected to be 
included in our sample was the following illustration of issues affecting the reliability of 
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technological error-trapping interventions as they are used in actual practice. We continue our 
examination of this issue in the Discussion section: 

Failure of technological error-trapping system as used in practice: 

Aircraft center of gravity loading became suspect when we received 
“stabilizer green band ” EICAS advisory message. The airplane did not 
like the center of gravity setting and hence , the trim setting for the 
weight and balance as received in the final manifest during taxi out. 

The flight manual procedure simply leads you to call maintenance after 
sternly telling you “do not take off 1” Maintenance is spring-loaded to 
simply assume it is an aircraft sensor error , and then to defer the 
system. We called dispatch immediately ...to confirm that , yes indeed, 
the airplane truly was loaded with a center of gravity this far forward. 

Our concern was that perhaps the plane had been loaded incorrectly 
(with a fitrther aft center of gravity, as it usually is on these flights at 
those weights...) and that the warning system was working correctly. 

We felt the plane ( weight compression sensors on the landing gear that 
detect a center of gravity') was perhaps telling us the truth , as it was 
intended to do , and warning us that the center of gravity was not as we 
were being told by operations and load planning. . .Perhaps the plane 
really was loaded more aft than reported. Until we could get that 
mystery solved , or until maintenance could confirm the weight/balance 
detecting system was in error , malfunctioning , or inoperative , we were 
not ready to accept a simple deferral and takeoff— and perhaps get a 
surprise pitch-up or inability to rotate for takeoff. Do you see our 
problem? We didn't know if the plane was telling us the truth, or if load 
planning was correct and the plane was wrong. We eventually. ..taxied 
back to a gate for confirmation from those who loaded the plane and 
from maintenance as to what had transpired so that we could make a 
decision to either defer and take off, or start opening cargo holds to see 
just where the cargo was loaded. ..Upon return to the gate, the station 
manager insisted her cargo loaders did in fact load the plane as 
reported— with a 15% center of gravity ...and she was not going to open 
cargo holds to check. She had a piece of paper signed by the car go! bag 
loaders and that was all the proof she needed. I felt this was kind of an 
in-your-face-captain attitude, “we're telling the truth , now take the 
plane and go fly” was the impression / was getting. Bottom line: 1) the 
plane, and the pilots, were not comfortable with such a “forward center 
of gravity;” 2) the flight manual procedure would lead one to believe 
the problem is always a maintenance problem— an error in the center 
of gravity sensing system— and not perhaps a true car go/ fuel/ bags 
loading problem and an incorrect center of gravity reported to the crew 
by load planning....” 


ACN 678751 



4.2.7 Role of Incorrect Information 

In 77 of the 1 12 errors, the pilots received incorrect information from ground personnel for use in 
the cockpit in making inputs to an FMS, laptop performance computer, data table, etc. Pilots’ use of 
that incorrect information was not per se coded as a separate error, unless the ASRS report revealed 
a specific, additional mistake by a flight crewmember such as omitting a required cross-check or 
verification. However, when the pilots did not identify the erroneous data as such, this was coded as 
failure to trap the error. Sixty-four of the 77 errors in received information were not trapped. 

In 34 of the 1 12 errors, the pilots received revised performance data after takeoff— too late to set 
flap/trim/V-speeds correctly for takeoff and ensure adequate performance (if the correct data 
required different settings from the incorrect data). These 34 instances are a subset of the 77 cases 
of pilots receiving erroneous information from ground personnel. Receipt of corrected performance 
data after takeoff usually alerted the pilots to the problem, enabling them to mitigate the associated 
threat for the remainder of the flight. In eight of the 1 12 errors, the pilots mistakenly used 
preliminary load data instead of final data that became available before takeoff. 

4.2.8 “Trapability”of Error by Ideal Procedures/Systems 

For 91 of the 1 12 errors, the case narrative provided adequate information for an informed, though 
subjective, assessment of whether SOPs ideally executed might have trapped the error (see Method 
section). Our analysis suggests that 88 of these 91 errors could in principle have been trapped. 

There was adequate information for 1 1 1 errors to allow us to consider whether these errors might 
have been prevented by technological systems, including automation, either already in existence or 
likely to be available in the near future. We found that 107 of these 1 1 1 errors likely could have 
been trapped, in some cases by systems already available on some aircraft or in the devices some 
airlines use in load preparation and in other cases by systems/devices that could be employed in the 
near future. The Discussion section provides examples of how well-designed and executed 
procedures and technologies might have prevented many of these errors. 

4.2.9 Role of Cognitive and Other Human Factors 

We performed an informed, though highly subjective, analysis of the ways in which cognitive 
factors and other human factors might have contributed to the 1 12 errors. Twelve distinct factors 
were identified and the frequency with which they contributed to errors is shown in Table 7 
(multiple codings of factors were made for some errors). Discrepancies not being salient, time 
pressure, rushing, and failure to cross-check were the factors most frequently contributing to errors. 
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Table 7. Role of Cognitive and Other Human Factors in Errors (n-1 12) 


Factor 

Frequency 

Example 

Discrepancy not salient 

22 

Ground personnel substituted empty weight for ZFW 
(22,000 pound error); V-speeds, rotation forces, descent 
gradients, pitch attitudes, and thrust settings seemed a bit 
abnormal but only recognized in hindsight after a hard 
landing prompted close review of the load sheet. (ACN 
558282) 

Time Pressure 

22 

Flight crew received final weights as the aircraft neared 
the runway and they were cleared to line up and wait. 
While rushing the final calculations, the first officer made 
a 10,000 pound error in adding the actual fuel onboard to 
ZFW for input into the FMS. (ACN 703116) 

Rushing 

20 

Flight crew felt time pressure from ground crew’s desire 
for on-time departure and rushed to push back in order to 
beat adverse weather; contributed to not noticing fuel load 
error in paperwork. (ACN 538960) 

Not cross-checking 

19 

Flight crew did not catch their own mistaken substitution of 
ZFW for GTOW and was not “in the habit” of checking the 
calculated against the planned GTOW, which would have 
caught the error. (ACN 632164) 

Expectation bias 

16 

During check of thrust rating indicator, thrust was actually 
set to Climb but “mind’s eye” saw the usual Takeoff 
setting. (ACN 854320) 

Disrupted/disruptive 
habit pattern 

13 

Flight crew recognized that performance calculations 
called for an unusual flap setting, briefed this correctly, 
but out of habit set the usual (incorrect) flap setting. (ACN 
625930). 

Distraction 

11 

Final weights arrived during taxi-out and flight crew was 
distracted communicating with ATC; contributed to 
failure to notice that actual weights had increased 
significantly above planned weights. (ACN 668766) 

Not being proactive 

10 

Flight crew suspected overweight aircraft based on 
sluggish takeoff performance; they compensated well 
during takeoff but did not recognize or act on the 
implications for landing. (ACN 795525) 

Fatigue 

8 

“Tired and somewhat fatigued” from four-day trip with 
extended duties and early wake-ups, the pilot did not 
notice that the performance data received on the flight 
deck printer was for the previous day’s flight, which was 
25,000 pounds lighter. (ACN 742390) 


continued on next page 
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Table 7. Role of Cognitive and Other Human Factors in Errors (continued) 


Factor 

Frequency 

Example 

Workload spike 

7 

Flight crew did not catch incorrect fuel value while 
rushing to input a newly received flight plan into the 
FMS and complete the before start checklist. (ACN 
530341) 

Prospective memory 

6 

Flight crew planned and briefed an unusual flaps-20 
takeoff, but after 45 minute delay, during taxi-out, 
called for and set the usual flaps-8 setting. (ACN 
842662) 

Confusion 

4 

Runway construction NOT AM provided length of the 
closure, requiring the dispatchers and crews to 
calculate the runway available; confusion about this 
led to overweight landing. (ACN 488866) 


4.2.10 Consequences of Errors 

Information was adequate to evaluate consequences of all 112 errors. Major consequences— 
including actual damage, handling/stability problems, significantly reduced performance, and 
violation of the aircraft's limitations— resulted from 16 of the errors. Another 59 errors led to 
minor consequences that could have been major if circumstances such as runway length or weather 
had been different and 5 other errors led to no worse than minor outcomes in any likely 
circumstances. Twelve errors led to an additional error and 20 errors were trapped, preventing any 
adverse outcome. 

Evaluation of Errors Having Major Adverse Consequences. The 16 errors having major outcomes 
are described in Table 8. 


Table 8. Errors Having Major Adverse Consequences (n=16) 


AC N 

Performance Error 

Consequence 

558282 

Ground personnel omitted passenger 
and cargo weights from gross weight 
calculation. 

Hard landing. 

669783 

Ground personnel provided incorrect 
baggage/cargo weight data. 

Exceeded aircraft structural limitation. 

529324 

Ground personnel provided fuel weight 
of 13,100 rather than 1 13,100 pounds, 
resulting in a 100,000-pound in error. 

Tailstrike during takeoff. 

585397 

First officer’s math error on CG 
calculation caused crew not to detect 
aircraft loading aft of CG limitation. 

Uncommanded pitch-up during takeoff 
roll below V 1 . 

580459 

Ground personnel failed to reflect 
heavier-than-normal bag weights in 
performance calculations. 

Uncommanded pitch-up during landing 
flare and also during taxi-in. 

632164 

First officer entered ZFW in the GTOW 
line of the FMS CDU, resulting in a 
39,000 pound error. 

Sluggish takeoff/climb and airspeed 
decay with stall buffet in cruise. 

472646 

(Flight crew surmised that) passenger 
and/or baggage weights provided by 
ground personnel were incorrect. 

Airspeed decay and stall buffet entering 
holding pattern at cruise altitude. 

804855 

Fuel weight entered by ground 
personnel as 12,000 rather than 120,000 
pounds, resulting in 108,000 pound 
error. 

Airspeed decay in cruise. 

695467 

Ground personnel used weights marked 
in kilograms on cargo boxes as weights 
in pounds; units not marked saliently on 
load plan. 

Inadequate takeoff and cruise 
performance. 

580202 

Ground personnel provided incorrect 
weight value for forward bin load. 

Aircraft exceeded structural weight 
limitation and aft CG limit for two 
flights. 

540556 

Cold-soaked laptop performance 
computer produced incorrect pitch trim 
value. 

Uncommanded pitch-up during takeoff 
below Vl/Vr speeds followed by high- 
speed RTO. 

672308 

Ground personnel delay in providing 
final weight closeout. 

Pushback and taxi-out while exceeding 
aircraft structural limitation, requiring 
gate return and inspection. 


continued on next page 
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Table 8. Errors Having Major Adverse Consequences (continued) 


ACN 

Performance Error 

Consequence 

658615 

Dispatch did not identify an aircraft- 
specific difference in the cargo 
compartment weight limit and the 
crew’s laptop performance computer did 
not reflect that limit. 

Exceeded aircraft structural limitation. 

625930 

Flight crew, distracted by operational 
and non-operational concerns and 
subject to habit capture, calculated 
performance data requiring an unusual 
flaps- 15 takeoff but set flaps to the usual 
5 degrees; 4,000 pounds overweight for 
the flap setting actually used. 

Long takeoff roll, out-of-trim condition 
during rotation. 

854320 

Flight crew misread thrust rating 
indicator during preflight preparation 
and took off using climb rather than 
takeoff thrust. 

Long takeoff roll, inadequate 
performance during initial climb. 

793424 

Ground personnel provided incorrect 
passenger and cargo weights, resulting 
in 40,000 pound error. 

Inadequate performance at planned cruise 
altitude, fuel over-burn during cruise 
requiring an intermediate fuel stop. 


By definition, none of these 16 errors was trapped. However, we determined that 1 1 of these errors 
could have been trapped by well-designed operating procedures— ground in some cases, cockpit in 
others— carefully followed (report narratives were not sufficient to evaluate four of the 16 errors). 
Further, eight of the 16 errors could have been trapped by a well-designed autonomous aircraft 
weight/trim sensor system (if used appropriately, of course). Another six errors might have been 
trapped with existing or potential automated error checking functions in ground computers and 
flight deck FMS systems. 

Cognitive/Human Factors Associated with Errors Having Major Adverse Consequences. Among 
these 16 errors with major consequences, most of the cognitive/human factors contributing to less 
consequential errors also played a role (Table 9). 
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Table 9. Role of Cognitive and Other Human Factors 
in Major Outcomes (n=16) 


Factor 

Incidence Among 
the 16 Errors 

Discrepancy not salient 

6 

Time pressure 

2 

Disrupted habit pattern 

2 

Workload spike 

0 

Fatigue 

2 

Expectation bias 

4 

Distraction 

2 

Prospective memory 

1 

Rushing 

3 

Not being proactive 

3 

Not cross-checking 

4 

Confusion 

0 


5. Discussion 

The goals of this study were to analyze how errors are made in generating and using aircraft 
performance data (weight and balance, with associated performance speed, thrust, and aircraft 
configuration values) and to identify measures to reduce errors and consequences of errors. This 
analysis covered the entire chain of steps from collection of raw load data, transmission of data 
from one party to the next, computation of aircraft performance, comparison to aircraft and runway 
limitations, entry into aircraft FMSs, and setting trim and flap controls. We were able to draw upon 
four recent studies that examined accidents and incidents involving incorrect aircraft performance 
data (Australian Transport Safety Bureau, 2010; Hughes & Godley, 201 1; Laboratory of Applied 
Anthropology, 2008; van Es, 2007) and upon investigation reports of specific accidents and 
incidents. We extended these studies in two ways: 1) collecting and analyzing ASRS reports; and 2) 
collecting information from airlines about the procedures by which performance data are generated 
and provided to flight crews. We then analyzed the cognitive and procedural factors contributing to 
error vulnerability and at the end of this section of our report we propose a wider range of measures 
to reduce these errors than has previously been published. 

From our literature review, we suspected that the small number of actual accidents resulting from 
use of incorrect performance data might be only the tip of an iceberg and that these accidents did 
not differ in kind from far more frequent incidents not ending in accidents— in other words, 
happenstance circumstances such as runway length determined whether incorrect performance data 
caused an accident. Our analysis of ASRS incident reports supports this view: The structure of 
incidents closely resembled that of accidents involving incorrect data. Further, some of the 
incidents in our ASRS set clearly exposed the flight to increased risk. 
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Airlines employ multiple safeguards to prevent and to catch data entry errors and in recent decades 
only a few fatal accidents 6 have been reported to result from these errors— which suggests that these 
safeguards are fairly effective. However, our review suggests that the risk of fatal accidents of 
passenger-carrying airliners is appreciable unless existing safeguards are enhanced. 

In this section we attempt to draw together findings from our literature review, discussions with 
airline personnel, and our analysis of ASRS data. Readers should keep in mind that many biases 
influence reporting of incidents to ASRS; therefore, we cannot infer from our ASRS sample 
conclusions about the relative incidence of events in the overall population of line operations. For 
example, we cannot infer which types of error are most common or which types of aircraft are most 
commonly involved. However, the incident descriptions in these reports provide insight into what 
kinds of errors occur, where they occur, and how they might be prevented or at least caught. Only 
two of the reports in our sample came from ground personnel (consistent with the overall ASRS 
database, which consists predominately of reports from pilots); thus, these reports provide much 
more detailed description of error circumstances in the cockpit than in ground preparation of 
performance data. 

5.1 Locus, Process Step, and Types of Error 

Consistent with findings from previous studies (e.g., ATSB, 2010, van Es, 2007; see the Literature 
section), more than half of the performance data errors in our ASRS sample were made in ground 
functions such as central load planning, ramp, gate, and station operations. Thus, the industry 
should direct attention to vulnerabilities throughout the performance data processing flow rather 
than focusing only on the flight crew’s actions, procedures, and equipment. 

Airlines differ in various aspects of how load information is generated and transmitted, calculations 
are performed, and data are entered into systems (not just the FMS). We identified three of the most 
common procedural structures airlines use to generate and apply load and performance data 
(Figures 1-3). Each of these structures can, in principle, work effectively— but in reality, errors 
occur from time to time at every step of the process in each. 

We rolled ASRS reports of errors into six clusters. The four most frequent clusters were also ones 
associated with substantial risk of adverse outcome: 1) ground personnel errors in obtaining, 
calculating, and entering weight data; 2) FMS data entry errors by flight crew; 3) errors made in 
checking against limitations; and 4) flap and trim configuration errors. A fifth cluster, fuel weight 
errors by either ramp personnel or pilots, was a cross-cutting category of errors identified from 
among the errors in the first two clusters. A sixth cluster, errors by pilots using cockpit laptop 
performance computers, was less frequent in our ASRS sample but equally important based on its 
role in accidents and serious incidents. 

Ground Personnel Errors in Obtaining, Calculating, and Entering Weight Data. These errors led to 
serious adverse outcomes, including a hard landing, exceedence of aircraft structural limitations, 
airspeed decay and stall buffet in high altitude cruise, flight diversion due to excessive fuel burn in 
cruise, and uncommanded pitch-up during landing flare. Most of these errors involved incorrect 
data entry, either when using a keyboard and computer entry screen or when handwriting on forms 
passed from one person to another. 


6 Transportation Safety Board of Canada, (2006); National Transportation Safety Board (2004); National 
Transportation Safety Board, (1998). 
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One of the airline load-planning specialists with whom we discussed this issue told us that his 
airline had automated the calculation of weight and balance (as a central load planning function), 
taking the human element out of the math and reducing the number of data entries in the 
calculation process by automatically transferring counts and weights for passengers, bags, and 
cargo that had been entered in the gate and ramp areas into the central computer. This is good, but 
the system remains vulnerable to entry errors in the gate and ramp functions that provide the 
counts and weight inputs. 

EMS Data Entry Errors. Only five errors in our ASRS sample involved the specific process step 
and error type of flight crews entering data into the FMS. Nevertheless, we examined these five 
errors closely (Table 4) because FMS input errors have been a particular industry concern and FMS 
data entry often occurs after weight values have been checked and verified, thus introducing new 
opportunities for errors close to gate departure when further opportunities for error trapping are 
limited. Four of these errors occurred as the pilots manipulated, processed, or checked information 
to be entered into the FMS: 1) not converting temperature units (ground systems provided 
Fahrenheit but the FMS required entry of the data in Celsius); 2) not noticing a discrepancy 
between the fuel gauges and fuel load data that ground personnel had incorrectly entered on the 
load sheet form, and consequently entering the incorrect data; 3) not noticing that ground personnel 
had not sent the final performance data to the flight deck, and then mistakenly entering the planned 
performance data in the FMS; and 4) using an incorrect data table to obtain FMS inputs (using the 
table that had performance data for an aircraft weighing 270,000 pounds, when the actual weight 
was 370,000 pounds). 

These four errors were classified as FMS data entry mistakes because the pilots committed them as 
they performed manipulations, calculations, or cross-checks that the company procedures required 
them to accomplish while making FMS entries. However, the errors actually occurred before the 
pilots’ fingers reached the FMS keyboard to enter the data. The Laboratory of Applied 
Anthropology (2008) study also found that most errors in FMS data entry were not keystroke errors 
by pilots but errors in preparing data for entry. In many cases, the flight crew were provided 
erroneous data but failed to use standard procedures for checking data; in other cases the flight crew 
made errors in manipulating correct data. 

The fifth FMS data entry error in our sample occurred when a pilot mistakenly entered the ZFW 
into the input field for the GTOW, resulting in a weight error of 39,000 pounds, quite large for a 
narrow-body aircraft. Using the erroneous weight, the FMS calculated V-speeds, engine thrust, and 
maximum allowable cruise altitude; consequently, takeoff and climb performance were sluggish, 
airspeed decayed, and stall buffet began in high altitude cruise. The same type of error was at the 
heart of several serious incidents previously discussed (ATSB, 201 1; Laboratory of Applied 
Anthropology, 2008; AAIB, 2011). 

Errors Made in Checking Against Limitations. In several errors, the performance data process 
produced valid weight and balance values for the aircraft, but then failed at the step of checking the 
calculated values against the limitations of the aircraft (e.g., maximum structural weight for taxiing) 
or against the specific takeoff conditions (e.g., the maximum weight that provides adequate climb 
performance over obstacles in the event of an engine failure). These errors included: 1) using the 
wrong inputs for weights or for performance parameters such as winds, runway, or temperature; 2) 
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not updating for changes in these parameters; and 3) simply not checking to see whether a 
limitation was being exceeded, given correct weight/balance and environmental data. 

Even though in most cases these errors did not cause overt consequences, such as structural damage 
or impaired control of the aircraft, the aircraft was caused to operate outside its tested and approved 
envelope, could have received unrecognized damage, and had reduced safety margins for dealing 
with events such as engine failure. For example, in our ASRS sample a delay by ground personnel 
in providing accurate final weight data led to an aircraft pushing back and beginning its taxi-out 
while exceeding the maximum allowable weight for taxiing. The violation was discovered by 
ground personnel before takeoff and the aircraft was contacted and returned to the gate. However, 
the limitation had already been exceeded and the maintenance inspection that followed found 
damage to a part of the landing gear. 

Flap and Trim Configuration Errors. Some of the most serious errors occurred at the very end of 
the performance data process. The pilots, according to self-reports, recognized before pushback 
from the gate that the performance data required them to use a flap setting that was unusual. 
However, when the time came to extend the flaps to the setting for takeoff— sometimes much 
later, depending on the airline’s procedures and on taxi delays — these pilots reverted to habit and 
set the flaps to their usual setting instead of the required setting, a phenomenon called “habit 
capture.” In one example, the pilots calculated performance data requiring an unusual flap setting, 
15 degrees, but later set the flaps to the usual setting of 5 degrees. The flight was 4,000 pounds 
overweight for the flap setting that they actually used. The result was a long takeoff roll and an 
out-of-trim condition during takeoff rotation. Further, if the flight had experienced an engine 
failure during the critical moments of takeoff, it may not have been able to clear all of the 
obstacles in the path of the departure. 

These habit capture errors are distinct from failing to extend the flaps at all, an extremely serious 
error, which also occurred once among the 112 errors and was caught by the takeoff configuration 
warning system. 

Fuel Weight Errors by Ramp Personnel and Pilots. Our ASRS sample included nine errors related 
to fuel loading, documentation, entry, or verification. Two of these were errors of more than 
100,000 pounds— one resulting in a tailstrike on takeoff and the other in airspeed decay at high 
altitude cruise. The ATSB (2010) found similar errors in its survey of accidents and incidents. 
Because fuel accounts for a significant percentage of the weight of an aircraft at departure, 
particularly for long range flights, errors in loading fuel and in recording and communicating fuel 
weight from the ramp to the flight crew can be a serious problem. Another concern is that fuel 
loading, recording, transmission, and entry are often separate from the procedures used for other 
weight elements (such as passengers and cargo) and thus may not be included in the verification 
procedures established to catch errors in these other weight elements. 

Our cases included examples of pilots performing required cross-checks (e.g., verifying the loaded 
fuel weight shown on the fuel gauges against the flight planned fuel weight) but failing to note a 
discrepancy— apparently expectation bias led them to see the planned/requested value instead of 
what the fuel gauges actually showed. Other fuel errors were subtle and easy for pilots to overlook; 
for example, a fuel handler inadvertently swapped fuel loads in two fuel tanks— the total fuel 
weight was correct but the CG was seriously off. 
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Errors by Pilots using Laptop Performance Computers. In our ASRS sample these errors involved 
pilots making incorrect entries into the laptop— either through their own errors or through receiving 
erroneous information— and incorrectly operating the laptop, all of which resulted in using 
incorrect performance data. The consequences of these errors were minor; however, they pose a risk 
of serious adverse consequences, as revealed by several accident investigations. The specific data 
entry errors that occurred in the Halifax and Melbourne accidents were also seen in the incidents 
reviewed in Laboratory of Applied Anthropology (2008): one instance of the pilots mistakenly 
using all of the performance data from the previous flight and two instances of the pilots entering 
the ZFW value into the entry field for the GTOW. Three additional entry errors involving 
substitution of ZFW for GTOW during laptop entries were reported in ATSB 2010. 

5.2 Consequences of Errors 

The magnitude of performance data errors in our ASRS sample ranged from small — a few 
passengers miscounted on a widebody aircraft, amounting to a trivial percentage of the GTOW —to 
very large— more than 100,000 pounds, comparable to the errors that caused accidents. The 
consequences of these errors ranged from none at all to tailstrikes that produced aircraft damage or 
difficulty controlling the airplane during takeoff or landing. Some of the events in our sample were 
similar to those that caused the Halifax accident (use of the previous flight’s performance data, 
although not in a laptop) and several other events were similar to the Melbourne accident (a 
significant error in entering weight was transferred to the FMS and used to calculate V-speeds). 

Most of the errors in our sample were of low consequence, which is consistent with what we 
learned from airline personnel: small errors in performance data are relatively frequent in routine 
operations. All of this is consistent with a pyramid picture in which tragic accidents such as Halifax 
are very rare; events without injury or substantial damage but which could have become accidents 
in different circumstances are more common, and events unlikely to cause accidents are far more 
common. Given that it is not feasible to catch all errors, the key questions are: 1) to what extent are 
the generation and detectability of errors with substantial potential for causing accidents similar to 
the generation and detectability of more trivial errors; and 2) how feasible is it to catch almost all 
serious errors, regardless of whether trivial ones slip through? 

An airline performance data manager told us, “The same processes that lead to a 20 pound error can 
lead to a 20,000 pound error.” This is true in many respects— for example, consider data entry 
errors: Omission of an entire weight element (such as passengers), numeric transpositions, and 
finger slip errors can be major as easily as minor. 

The numerous errors involving performance data corrections sent to the crew after departure are 
mostly minor. The correction for last minute added/subtracted passengers and bags is typically a 
small percentage of total weight and does not alter performance significantly in most cases. 

(Indeed, if the pilots had not received these small corrections they probably would not have noticed 
any effect on performance.) 

One airline expert pointed out that the frequency of performance data errors reported may partially 
be a function of the airline having a sophisticated system for detecting errors, correcting them, and 
alerting pilots to the revised data; the same errors can pass through less advanced systems unnoticed 
unless there is a highly negative outcome, such as a tailstrike. An airline with a good system may 
appear to have more errors than an airline with a poorer system in which few errors are identified, 
but an effective program can provide insight into the ways errors are generated and lead to methods 
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for error-trapping. What we don’t know, can hurt us. This expert’s airline established a system for 
notifying pilots of performance data corrections only if the correction (1) exceeded an error 
percentage threshold and (2) could be sent to the flight deck prior to departure. This system 
intentionally suppressed small corrections and ones that might interrupt the pilots during the actual 
takeoff roll. 

A small number of the errors in our sample apparently involved complete failures of the airline’s 
system to transmit final weight data to the flight crew on the particular flight. This kind of failure is 
quite serious because it increases the risk that pilots will mistakenly use the preliminary data as 
final data in the FMS 7 and the risk of using the previous flight’s data (the cause of the Halifax 
accident). Some of the failures to provide final weight data were caught by the pilots but workload 
and distraction during taxi-out undercut pilots’ ability to catch these failures. 

5.3 Error Trapping 

Only 20 of the 112 errors in our ASRS sample were caught; however, this should not be taken as an 
indication of error-trapping effectiveness of the overall system. Pilots would not be aware of errors 
trapped before data reaches them and pilots are more likely to report their own errors they did not 
immediately catch in order to obtain immunity from FA A action provided by ASRS. However, it is 
noteworthy that of the 15 errors which were trapped and for which we had enough information to 
determine how they were trapped, only two were trapped by systems/automation and two were 
trapped by execution of SOPs. The other 1 1 were trapped by pilots who sensed that something was 
amiss and went beyond SOPs to resolve the uncertainty. This suggests that “non-procedural” error 
trapping is important and we will return to this in the subsection on Mitigation. 

We determined (subjectively) that the great majority of the errors in our ASRS sample could in 
principle have been trapped if personnel at each step in generating and using load/performance data 
had followed SOPs as intended and if the SOPs were fully established and well defined. Similarly, 
we determined that the great majority of these errors could, in principle, have been caught by 
technological systems either generally available on airliners or currently feasible but not in 
widespread use. Given that most of these errors could in principle have been caught, why were they 
not? In examining that question, we must keep in mind that neither our ASRS data nor the several 
studies discussed in the Literature section allow one to determine what percentage of errors are 
caught among the millions of airline flights taking place every year. The industry needs this 
information to fully evaluate the effectiveness of existing procedures and technology; nevertheless, 
our study sheds some light on the issue. 

Conceivably, the vast majority of errors are actually caught and we are seeing only a relatively 
handful that slip through; however, our analysis and our discussions with airline personnel suggest 
that enough errors slip through to pose appreciable risk of major accidents. Our analysis suggests 
that existing error-trapping procedures sometimes fall short for five reasons: 1) many opportunities 
for error occur along the chain of generating and using load and performance data for the millions 
of flights that occur annually; 2) existing procedures do not address all of those opportunities and in 
some cases create additional opportunities; 3) some aspects of procedures are not well aligned with 
the real-world aspects of flight operations; 4) procedures do not fully take into account human 


7 Apparently, some airlines require pilots to enter the preliminary data in the FMS, theoretically to save time 
by completing the flight deck set-up with the preliminary data and then updating only if the final data are 
different. 
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performance characteristics and limitations and do not provide adequate guidance to human 
operators; and 5) the error-trapping potential of automated systems has not yet been fully exploited. 
We discuss these reasons mainly with examples from the flight deck because that is where we have 
the most information; however, the principles apply equally to ground procedures. 

Many Opportunities for Error. Multiple steps of recording, entering, and calculating data occur 
before pilots enter resulting data into the FMS and errors may occur at each step (Table 3). 
Safeguards are required for each step but this could lead to a very large and cumbersome checking 
system. Fortunately, however, it is possible to reduce the number of steps as we discuss in our final 
section on Mitigation. 

Existing Procedures Do Not Address All Opportunities for Error. One widely-used and appropriate 
error-trapping procedure requires one pilot to check the actions of another. But if the two checks are 
not fully independent they will fail if based on a common error. For example, a procedure may 
specify that the captain and first officer independently derive V-speeds from a table, but if both 
pilots enter the table using the weight values incorrectly calculated by the first officer then the 
speeds they obtain from the table will both be wrong. Similarly, all of the procedural verification by 
station operations, load planners, and pilots can be undone by a prior paperwork error on the ramp. 
Further, although all airlines have a procedural check that the flaps are extended before takeoff, this 
procedure may not specify checking that the position to which the flaps were set is indeed the 
setting required by the final weight manifest. 

Some procedural aspects can increase vulnerability to error. For example, entering preliminary 
weight and performance data into the FMS increases the risk of using incorrect data if the final data 
are not received or not noticed during taxi-out. The risk is further exacerbated if SOP allows or 
requires pilots to start taxiing before final data are received and entered— a practice frequently 
reported in our ASRS case sample. 

Poor Alignment of Procedural Checks with Realities of Actual Flight Operations . Procedures are 
often written rather idealistically, as if human operators are performing tasks in a vacuum one at a 
time without interruption, with the information needed for each task being available when needed. 
The reality is that operators often must juggle multiple tasks concurrently, are often interrupted, and 
are not provided information when they need the information. Late changes in taxi instructions, 
departure runways, and departure routings force pilots to re-do performance calculations and data 
entry at a time when they are busy with other tasks. This conflict between the ideal and the real 
contributes to many errors and undermines the effectiveness of error-trapping procedures 
(Loukoupoulos, Dismukes, & Barshi, 2009). 

Updated information sometimes arrives too late to be acted on. For example, ground personnel may 
perform a discrepancy resolution procedure and discover an error but the corrected information may 
not reach the flight crew until after takeoff. Ground procedures directed at resolving discrepancies, 
according to our airline sources, seem to be more oriented to paperwork reconciliation than to 
getting information to the flight in time. 

Procedures Not Well Matched to Human Performance Characteristics and Limitations . In both 
previous studies and in our ASRS data we found examples of pilots executing error-checking 
procedures but doing so inadequately or incompletely. For example, in some cases we suspect 
“looking without seeing,” in which the individual looks at an item to be checked but does not see 
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that something is wrong (Dismukes, Berman, & Loukopoulos, 2007). Looking without seeing may 
occur because the individual does not gaze at the item long enough to fully process the information, 
which is exacerbated by time pressure, and by expectation bias. This bias occurs in part because the 
item checked is correct the vast majority of the time. Individuals may also not notice a discrepancy 
because it is not visually salient; for example, in one ASRS case in our sample the pilots took off 
without having received final performance data, mistakenly using a weight manifest form that had 
remained in the cockpit from a previous flight and not noticing the incorrect date and flight number 
in the small print on the form. Several occurrences of failures in what is called “prospective 
memory” occurred; for example, a pilot noticed a discrepancy and intended to resolve the 
discrepancy later when he had a free moment. But the pilot became busy with last minute 
preparations for takeoff and forgot to go back to the discrepant item. 

Time pressure, rushing, distractions, interruptions, and disruptions contributed to inadequate 
execution of error-checking procedures (Table 7). We suggest that airlines do not provide enough 
guidance to personnel on how to manage the pressures nor do they provide explicit guidance on 
resolving discrepancies— how much discrepancy is acceptable and how to resolve unacceptable 
discrepancies. Some procedures fail to specify pilots should look at and what to verbalize when 
performing a cross-check. We will discuss these issues in more detail in the Mitigations subsection. 

Airlines often fail to explain to pilots why redundancy in checking procedures is necessary and, in 
fact, checking procedures may be cumbersome to execute under time pressure and multitasking 
demands. This, coupled with expectation bias, may lead to inappropriate streamlining and lax 
execution of procedures. 

Automation Capabilities Not Fully Exploited. Automated systems can greatly reduce opportunities 
for human error and can flag errors, but many systems in current use do not go as far as they could. 
For example, all airliners have takeoff configuration warning systems that warn crews if flaps are 
not set but most of these systems do not alert the crew if the flaps are set to a position inconsistent 
with the performance data in the FMS. Also, some older FMSs do not internally calculate V-speeds 
and trim settings, requiring pilots to input this information manually with attendant opportunity to 
error and not providing the opportunity to catch errors by comparing the performance data 
calculated earlier in the process to the values internally generated by the more advanced FMS. 

In the next section we draw upon previous studies and develop our own suggestions for numerous 
ways that error trapping procedures and automated systems could be improved. 

5.4 Mitigation of Performance Data Errors 

In this discussion we focus on the six clusters of performance data error that our ASRS case study, 
results of other studies, and findings of accident/incident investigations suggested to have the 
greatest risk of serious adverse consequences: 1) ground personnel errors in obtaining, calculating, 
and entering weight data; 2) FMS data entry errors by flight crews; 3) errors made in checking 
against limitations; 4) flap and trim configuration errors; 5) fuel weight errors by ramp personnel or 
pilots; and 6) errors by pilots using laptop performance computers. For each of these clusters of 
error we evaluate two risk mitigation paths: 1) reducing the occurrence of the errors; and 2) 
enhancing the reliability of detecting and correcting the errors once they have occurred. 

Mitigating Errors by Ground Personnel in Obtaining, Calculating, and Entering Weight Data. 
These errors can be reduced by eliminating manual data entries (whether on forms or computer 
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keyboards) whenever possible. For example, automatically scanning passenger boarding documents 
at the gate can provide a passenger count to the weight and balance computing system without 
manual intervention, which is prone to error. Similarly, cargo and baggage can be scanned as it is 
loaded on the aircraft, thereby minimizing manual entries and providing an independent 
confirmation of counts and scans done earlier in the process, such as at the cargo facility . 8 

These errors can be further reduced by having performance data subsystems exchange their data: 
the ramp data-entry system should transmit its counts to the central load-control computer rather 
than simply generating a printout for central load personnel or pilots to hold in their hands and use 
to manually re-enter the data into their own systems. Likewise, the output of load calculations 
(whether from a central computer or flight deck laptop computer) should be uplinked directly to the 
aircraft’s FMS to eliminate manual data entry at that stage. 

One procedural means of trapping errors made during the ground functions is to compare the 
preliminary values for TOWs (and subcategories such as ZFW, passenger weight, etc.) that are 
generated during the flight planning process with the corresponding final weight values. This 
comparison can be done by ground personnel or by pilots whenever the final load calculations have 
been completed. The advantage of this comparison is that the preliminary weights are based on pre- 
bookings and planned fuel loads while the final weights are calculated independently. Some airlines 
have implemented this comparison but others have not. 

Further, our case data and discussions with airline personnel suggest that this comparison procedure 
can be incomplete even when it has been established in the SOP. For example, several airlines 
established a threshold discrepancy value between the preliminary and final weights that requires a 
response by the pilots, most often contacting dispatch for a new flight plan that includes 
recalculation of the fuel requirement for an aircraft that is heavier than preliminarily planned. 
However, the airlines using this procedure did not require pilots to act on the discrepancy if the 
final weights were less than the preliminary weights. This was probably because, from a dispatch 
perspective, the predicted fuel burns in the flight plan and preliminary load planning data for a 
heavier aircraft would always be adequate for an aircraft that is actually lighter than planned. 
However, it is precisely this condition— a calculated final weight being less than the preliminary 
weight— that might signify that the final weight or its components were incorrect. For example, the 
weight of the passenger load could have been inadvertently omitted altogether from the 
calculations, as occurred in some of the ASRS reports. In order for the comparison of preliminary 
vs. final weight to be an effective trap for this error, discrepancies in either direction must be 
resolved. 

Our discussions revealed that airlines routinely attempt to resolve load discrepancies but apparently 
the norm is to do so after gate departure, frequently only after takeoff and even after landing. This 
practice does not fulfill the role of mitigating risks from performance data errors. We suggest that 
preliminary weights be compared to final weights and discrepancies resolved before departure and 
that this be universally established in performance-data SOPs until the equivalent error-trapping 


s We note, however, that an automated system relying on scanning requires back-up procedures in case 
equipment malfunctions. We found errors that occurred when personnel were forced to revert to back-up 
procedures with which they were unfamiliar. Airlines should treat using back-up procedures as a potential 
risk, anticipate the need for their use, and enhance their reliability by training personnel on them. 
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function can be reliably performed using other procedures or systems. 9 Once a discrepancy has 
been identified, resolution might take the form of placing gate departure on hold and then 
backtracking through the loading processes until verifying whether missing weight was, in fact, 
aboard the aircraft, and data calculations re-done if necessary. Resolution might also be 
accomplished by manually checking items on the load sheet for gross errors such as a completely 
missing passenger count. However, a note of caution: We stress that preliminary load data should 
not be entered into the FMS where they might be mistaken for final data. 

We suggest that airlines should establish formal procedures for discrepancy resolution, establishing 
and training specific methods (e.g., how to re-check basic performance data such as passenger 
counts to identify the source of a discrepancy, who to contact for assistance, how to obtain an 
independent, third “tie-breaker” calculation). Because subtle cognitive forces such as expectation 
bias and “looking without seeing” tend to undermine discrepancy detection and resolution, airlines 
should actively train and check formal procedures so that they become norms. Training should 
explicitly inform individual operators about the rationale for independent checks and the ways 
independence can be unwitting undermined. 

Error trapping through technological means can be effective at several steps in the performance data 
process vulnerable to errors by ground personnel. Some errors can be caught early in the process, 
for example, by programming a central load-planning computer to automatically flag omission of 
an entire weight category. However, this approach can miss catching even some gross errors that 
can have serious consequences because weight values normally vary over a wide range (e.g., 
correct fuel weights for the same aircraft may range between 40,000 and 250,000 pounds). 

There has been long-term government and industry interest in developing and fielding an onboard 
TOPMS, which in principle could detect and flag any significant weight discrepancy affecting 
performance (NTSB, 1982; ATSB, 2009). This system uses inertial reference sensors to measure 
acceleration during the takeoff roll. An aircraft loaded more heavily than reflected in its 
performance calculations would accelerate more slowly than expected. Slower-than-expected 
acceleration could also result from deficient engine thrust, runway contamination, and other 
factors— regardless of the reason, if the aircraft does not accelerate properly it may not perform 
adequately for the particular runway and obstacle clearance. Of course, to be effective and to avoid 
introducing additional risks, the TOPMS would have to provide its warning early enough in the 
takeoff roll to give the pilots substantial time to react and reject the takeoff while still at low speed. 

Some of the stumbling points in developing a practical TOPMS are (1) obtaining comparison data 
of expected acceleration performance for all aircraft weights and environmental conditions and (2) 
determining proper error tolerances for sounding the alarm for significant performance deficiencies 
but avoiding false alarms or unnecessary warnings during the critical takeoff maneuver. Also, even 
though an effective TOPMS would be valuable, it would provide its warning at a critical high 
workload period— which is not the most desirable approach. It would be far better to develop a 
system to alert pilots before takeoff. We are not aware of any current effort to field a TOPMS. 

Another extremely valuable technological approach to error trapping is to have the aircraft 
autonomously sense its weight and CG. Several current transport aircraft types are equipped to 


9 We recognize that this may slightly delay some flights but we feel that the improvement in safety is well 
worth the cost until reliable but faster and/or less expensive technological means of error trapping can be 
implemented. 
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derive their weight from strain gauges attached to the three landing gear assemblies. The CG can be 
derived by triangulating from the known locations of the landing gear on the fuselage. For example, 
some Airbus models are equipped to calculate aircraft weight and currently include these data 
among the parameters that are stored for accident investigation (flight data recorder) and for flight 
operations quality assurance (quick access recorder). Some Boeing models are equipped to sense 
aircraft weight/CG and warn the crew if the aircraft’s pitch trim is set outside the expected bounds 
for the CG location. 

The technology for aircraft weight and CG sensing is not complicated. Theoretically, such a system 
could substitute for all of the performance data processes currently used to determine aircraft total 
weight from individual load components. The FAA and other authorities have issued standards for 
approval of these systems as primary sources of weight/CG data. These standards, though, are 
difficult to meet because reliability and accuracy would have to be extremely high; without 
independent verification, any errors in the aircraft weight/CG sensing system would be difficult to 
catch and could have major adverse consequences. We are not aware of any efforts by an airline to 
implement such a system as the primary source of weight and balance data. 

However, the autonomous aircraft weight/CG sensing system may be more viable and more readily 
implemented as a secondary source of data; that is, as a valuable cross-check for performance data 
calculations rather than as a substitute, as suggested by the NLR (van Es, 2007). Such a system 
would alert to discrepancies between its own sensed values and those derived from the performance 
data process and entered in the FMS. The latter calculations would remain the primary and 
controlling values. An acceptable margin of difference would have to be established beyond which 
the cause would have to be determined or the performance data processes would have to be 
thoroughly re-checked at all stages to verify their accuracy. We suggest that the tolerance for an 
acceptable discrepancy could be expressed as a percentage of weight but it would be reduced as an 
aircraft structural or operating limitation were approached. Used in this secondary, error-trapping 
role prior to pushback, the only apparent downside would be the risk of false alarms causing 
excessive re-checking of the primary data. Overall, this would be an excellent system to catch large, 
serious errors in weight/CG data. 

Although automated systems can be highly valuable in preventing and trapping errors, they do 
come with some drawbacks that must be dealt with. If a system has more than a very few false 
alarms, human operators tend to discount its warning. Our ASRS case data included an example of 
this tendency in which disregard of an inadequately reliable automated “green trim band” warning 
became institutionalized among in the procedures and practice of both the pilots and maintenance 
technicians of an airline. Operators also tend to develop “automation complacency” (Parasuraman 
& Manzey, 2010), especially if the system’s workings are not transparent, and they unwittingly 
relax their own error-checking procedures. Research is required to devise ways to counter these 
reactions to automated systems; in the meantime, training and procedures should explicitly address 
the vulnerability. 

Mitigating FMS Data Entry Errors by Flight Crews. These errors occur near the end of the 
performance data process, often in a period of significant distraction, interruption, and high 
workload on the flight deck just prior to pushback from the gate. Further, some airlines require 
pilots to make or cross-check FMS data entries during taxi to the runway, an even more demanding 
period that increases vulnerability to error. Airlines can reduce vulnerability to error in FMS data 
entry by establishing procedures requiring that pushback be made only after final performance data 
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have been received, entered, and verified on the flight deck. Further, airlines can provide ground 
personnel and pilots with training and encouragement in controlling rushing and enhancing 
deliberation. 10 

One form of FMS data entry error of particular concern has been substituting ZFW for GTOW, 
prompting the NTSB to recommend (in Safety Recommendation A-05-05; see FAA, 2005) 
modifying the FMS system software so that it will accept entry of only one of these two weights: 
ZFW. The source for data entry to the FMS — load manifest or laptop— also would have to display 
only that one weight to the pilots. Some, but not all, FMS were modified as a result of these 
recommendations. Occurrence of this error in our ASRS sample, with serious adverse 
consequences, suggests that this modification should be completed for all aircraft. An autonomous 
weight and balance sensing system, coupled with discrepancy resolution procedures, would also 
address this form of error. 

For the many FMS in current use that are not capable of internally calculating V-speeds and trim 
parameters based on weight data, the pilots have to manually enter at least some of these 
parameters from the source (load manifest or laptop display). Pilots are vulnerable to error in 
making the entries which can result in inadequate aircraft performance. The best way to prevent 
these errors is to automatically uplink both the weights and V-speeds directly to the FMS. The 
source for this uplink is the central load-planning computer in existing installations but it is 
possible that the capability could also be developed for laptop performance computers to be 
directly linked to the FMS. 

Procedural cross-checks also help with error-trapping. To make these procedures as reliable as 
possible, we suggest that airline SOPs should specify the crewmember who challenges and 
responds to each performance value entered and should specify the data source to be consulted in 
making the cross-check. For example, in cross-checking V-speeds the SOP might specify: first 
officer reads VI , Vr, and V2 from the PFD and the captain confirms these values by looking at and 
reading from the load manifest. 

Because error-trapping procedures are not perfectly reliable, they should be supplemented by an 
independent means of verifying parameters. For those advanced FMS that are capable of internally 
generating V-speeds, airlines should take advantage of this capability by requiring pilots to cross- 
check the FMS’s internally generated values against those derived from an external source (load 
manifest or laptop performance computer calculations shown on its display). The external source 
will consider all of the variables in calculating the parameters while the FMS internal calculations 
may not so the FMS should be considered the secondary source for a gross error check. Even this 
cross-checking between internal and external sources is incomplete, because both depend on the 
same weight inputs; hence weight should also be independently verified, ideally by an autonomous 
weight and balance sensor system. 

While pilots are entering performance data into the FMS, they have an opportunity to assess 
whether these data are in the normal range for the type of aircraft, drawing upon their previous 
experience with normal values under the conditions for the current flight. When pilots notice that 
parameter values seem to be out of normal range, they may be prompted to track down the apparent 
discrepancy and discover an error in the data. This informal or “non-procedural” error-trapping can 


10 Rushing, in response to high workload and time pressure, contributes to many forms of error and 
vulnerability to accidents (Loukopoulos, Dismukes, & Barshi, 2009, p. 129). 
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catch errors made during FMS data entry as well as those made earlier in the process. Of the 20 
errors trapped in our ASRS sample, 1 1 were trapped by this informal process. ATSB (2010) and 
Laboratory of Applied Anthropology (2008) cited similar examples. 

Non-procedural error-trapping is probably most effective at catching large errors, which are the 
ones most likely to have serious consequences; however, it cannot work in all circumstances. Pilots 
new to an aircraft type are not likely to have a “gut feel” for appropriate performance data. Also, 
pilots operating large, long-haul aircraft (especially more than one variant of the same aircraft type) 
over a variety of routes encounter a wide range of fuel loads and payloads and a correspondingly 
wide range of V-speed and trim values. Thus, the weight information given these pilots may be 
within the range they normally encounter but still quite wrong for the current flight. 

Nevertheless, pilots may benefit from training about the performance parameters that are typical for 
their aircraft and operations, especially if the aircraft is used in a relatively narrow range of 
operational conditions. Although non-procedural error-trapping is not sufficiently consistent and 
broadly applicable to be a primary defense against error, the number of cases in which it has saved 
the day suggests that it is worthwhile for airlines to help pilots develop and use this informal 
defense mechanism. 

Mitigating Errors Made in Checking Against Limitations. Airline safety depends on operating 
within approved limitations and not compromising the associated performance guarantees and 
safety margins for handling contingencies. To mitigate errors involving violations of limitations, 
many of the checks of parameters against the limitations can be automated. Release of final 
performance data to the flight deck can be inhibited until this check is completed for systems using 
a central or station-based process. Laptop performance computers can, and usually do, flag 
violations of limitations; however, some early model laptops do not flag violations saliently. (Some 
simply lock their displays without alerting the pilots that a violation had been detected.) 

Last minute changes pose a special challenge. Whenever there is a change in a load weight, count, 
or position on the aircraft, there must be a corresponding recalculation of all associated 
performance data with a recheck of limitations. Late changes and untimely notification and 
recalculation resulted in many of the errors in our ASRS sample, although these changes are 
typically small. However, in the case of violation of a limitation, even a small percentage error may 
place the operation outside the approved envelope and compromise safety margins. Further, a 
change in external variables— such as runway, wind, and temperature— may also cause a flight to 
exceed a limitation. Systems for checking limitations and coping with changes should be designed 
to detect and adjust for all of these factors. 

Mitigating Flap and Trim Configuration Errors. Habit capture errors, in which the pilots set flaps 
to the normal position instead of the position required by unusual conditions, are quite difficult to 
trap reliably with existing procedures. Pilots who make these errors may follow prescribed cross- 
checking procedures but forget that they had planned for an unusual setting by the time they set 
the flaps (especially if flaps are set during taxi) and revert to the setting used in thousands of 
previous flights. 

Vulnerability to these habit capture errors can be reduced to some extent by a combination of 
training and modifying existing procedures. Airlines should explicitly train pilots about 
vulnerability to habit capture when atypical flap settings are required. Pilots may want to use 
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personal techniques to remind them to use the atypical setting— for example, creating a salient cue 
such placing an empty coffee cup over the flap handle. Checklists can be modified to require a 
cross-check of the required (atypical) flap setting as shown in the performance data against the 
actual flap setting and pilots should be informed that this cross-check is as important as the 
traditional cross-check of the flap selector against the flap indicator. Details of the cross-check 
should be specified explicitly in SOPs and training (e.g., “When you repeat ‘flaps fifteen’ you 
should read that number from the load manifest paperwork”). 

Technological measures can also help trap these errors. On some aircraft the FMS can sense the 
actual flap setting and in this case the flap setting required by the performance data process can be 
entered into the FMS (preferably by automatic uplink). Then, when the pilots set the flaps, the FMS 
can determine whether the setting is correct and alert the pilots if it is not. 

Trim setting errors can be trapped using similar technology. The CG value from the performance 
data calculations would be uplinked or manually entered into the FMS, which would compare this 
value to the actual CG location sensed by an autonomous weight/balance-sensing system. The FMS 
would automatically check the sensed position of the horizontal stabilizer trim, and if it differed 
from the required position, alert the pilots. 

These enhanced automatic cross-checking functions would require updating many current FMS 
systems and for many aircraft would require adding databus communication between control 
surface position indicators and the FMS. We suggest that these improvements, though not cheap, 
would significantly improve trapping of these serious errors and reduce vulnerability to accidents. 

Mitigating Fuel Weight Errors by Ramp Personnel or Pilots. These errors require special attention 
because they can be quite large, amounting to a substantial percentage of GTOW. To reduce these 
errors, airlines should provide fueling, operations, and flight crew personnel explicit training about 
the ways in which fuel errors can occur. Also, airlines should review the procedures used by all of 
these personnel and develop specific cross-checks that provide reliable error-trapping capability. 
Beyond this, with the fuel loading, weight calculations, data entries, and verification procedures 
often separated by time, place, and employee group from those of the other weight components, an 
autonomous aircraft weight and balance sensor system may be the most effective error-trapping tool 
for this error of serious potential consequence. 

Errors by Pilots using Laptop Performance Computers. Many of these errors can be discovered 
through procedural cross-checks and verifications between: 1) the values on the data source for the 
pilot’s laptop entries (usually a load manifest that is handed to the crew or received on the flight 
deck via ACARS); 2) the weight and count values shown on the laptop display after data entries are 
complete; and 3) the calculated performance parameters (V-speeds, etc.) entered into the ultimate 
flight deck destination (speed bugs, flap and trim settings, etc). We found that many airlines have 
established such procedures; for example, one pilot reading from the laptop display and the other 
pilot cross-checking the FMS display. 

However, as we have discussed, the effectiveness of these cross-checks is sometimes compromised 
in actual practice. Effectiveness is best accomplished if airlines design the procedures to be very 
specific about what each pilot looks at, cross-checks, and verbalizes in performing the task. 

Training should be equally specific to ensure that habits are established and norms are set for the 
procedures to be performed as designed. 
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Because procedures are not perfect error traps, additional countermeasures are needed, such as an 
autonomous weight and balance sensing system. However, while this system would help catch 
errors involving weight/count entries and weight calculations, it would not trap errors involving 
the laptop program’s outputs of the other performance parameters (i.e., V-speeds, flap settings, 
etc.). These output errors can be addressed by the measures previously discussed under FMS data 
entry errors. 

5.5 Summary of Error Mitigations 

Table 10 summarizes our suggestions for strategies for reducing and trapping performance 
data errors. 


Table 10. Summary of Mitigation Strategies for Errors with Major Consequences 


Error Cluster 

Key Vulnerabilities 

Error Reduction 
Strategies 

Error Trapping Strategies 

Errors by ground 
personnel with 
weights/counts. 

Manual data entry. 

Scan loads as they are 
boarded. 

Compare predicted to 
final performance data. 

Last minute 
changes. 

Link sub-systems so 
data are passed 
automatically. 

Cross-check with 
independent counts. 



Cross-check with 
autonomously sensed 
weight/balance. 



Non-procedural gross 
error checks by pilots. 



Resolve discrepancies 
revealed by all above. 

Errors with fuel 
weights. 

Manual data entry. 

Train ground and 
flight crews about 
these vulnerabilities. 

Cross-check with 
autonomously sensed 
weight/balance. 

Inadequately 
developed 
procedural cross- 
checks. 


Non-procedural gross 
error checks by pilots. 

Lack of salience of 
cues to error. 


Resolve discrepancies 
revealed by all above. 


continued on next page 
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Table 10. Summary of Mitigation Strategies for Errors with Major Consequences (continued) 


Error Cluster 

Key Vulnerabilities 

Error Reduction 
Strategies 

Error Trapping Strategies 

Errors by 
pilots using 
laptop 

performance 

computers. 

Manual data entry. 

Train pilots on 
managing workload and 
distraction. 

Establish and train 
detailed procedures for 
cross-checking manual 
entries and transfers. 

Manual transfers of 
laptop outputs into 
subsequent data entries. 

Automatically uplink 
input data to laptops and 
downlink output data 
from laptops to FMS. 

Cross-check with 
autonomously sensed 
weight/balance 
(effective for weight 
errors only). 

Inadequately developed 
procedural cross-checks. 


Cross-check of V-speed 
and configuration 
parameters between 
laptop calculations and 
internal FMS 
calculations. 

Last-minute changes. 


Non-procedural gross 
error checks by pilots. 



Resolve discrepancies 
revealed by all above. 

Errors by 
pilots with 
FMS data 
entries. 

Manual data entry. 

Train pilots on 
managing workload and 
distraction. 

Establish and train 
detailed procedures for 
cross-checking manual 
entries and transfers. 

Mistaken substitution of 
ZFW/GTOW values. 

Standardize on either the 
ZFW or the GTOW 
entry. 

Automatic cross-check 
of FMS weight entries 
with autonomously 
sensed weight/balance. 

Inadequately developed 
procedural cross-checks. 

Eliminate the other field 
from the source data and 
FMS input screen. 

Automatic cross-check 
of V-speed and 
configuration 
parameters between 
manual/uplinked FMS 
inputs and internal 
FMS calculations. 

Last-minute changes. 

Automatically uplink 
input data from central 
computers or laptops to 
FMS. 

Non-procedural gross 
error checks by pilots. 


Suppress pushback until 
all performance data 
entries are completed 
and cross-checked. 

Resolve discrepancies 
revealed by all above. 


continued on next page 
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Table 10. Summary of Mitigation Strategies for Errors with Major Consequences (continued) 


Error Cluster 

Key Vulnerabilities 

Error Reduction 
Strategies 

Error Trapping Strategies 

Errors in 
verifying data 
against 
limitations. 

Manual data entry. 

Train pilots on 
managing workload 
and distraction. 

Establish and train 
detailed procedures 
for cross-checking 
manual entries for 
performance data 
including runway/ 
environmental factors. 


Inadequately developed 
procedural cross- 
checks. 




Last-minute changes in 
load data or runway 
/environmental data. 

Suppress pushback 
until all performance 
data reconciliations 
are completed and 
last-minute corrections 
provided to pilots. 



Alerting to limitation 
violations not 
adequately salient on 
some computer 
displays. 

Provide salient 
alerting to limitation 
violations on computer 
displays. 


Errors by pilots 
in setting flap 
configuration. 

Habit capture of 
unusual flap setting by 
the usual one. 

Train pilots about 
these specific 
vulnerabilities. 

Automatic cross- 
check between 
required flap/trim 
settings as uplinked to 
the FMS and the 
actual settings on the 
wing and stabilizer. 


High workload during 
period between 
receiving the required 
flap setting and 
extending the flaps. 


Establish and train 
procedures to specify 
the cross-check 
between actual 
configuration and 
required configuration 
as shown on a source 
document. 


Extended time delay 
between receiving the 
required flap setting and 
extending the flaps. 
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The risk of serious adverse consequences from these errors warrants efforts to improve SOPs and 
develop technologies for error trapping. Performance data errors can be reduced, to some degree, by 
procedures and technology that minimize manual data entry. SOP cross-checks and verifications 
can be defined, trained, and inculcated into line norms so as to provide and maintain independent 
verification of data entries. Informal “gut checks” and heuristics pilots sometimes use to identify 
out-of-bounds performance data can catch some errors, especially gross errors that may have the 
highest consequences, but such ad hoc efforts are not reliable enough to depend on. Some airlines 
have established a network of redundant and overlapping procedural cross-checks to improve the 
overall reliability of error-trapping," but as the ATSB noted in its investigation of the Melbourne 
accident, too many overlapping cross-checks can cause confusion and undercut human operators’ 
perception of the importance of each individual procedure. 

What is essential in airline procedural improvements? Probably the two most essential points are 
(1) make discrepancy resolution a norm in line operations (supported by procedures and training) 
and (2) recognize and account for the challenge of the last-minute changes that are inherent in 
line operations. 

On the technology side, the most reliable, effective, and independent means to trap weight errors 
from most sources would be an autonomous onboard weight and balance sensing system. Such a 
system is feasible with current technology and would provide a secondary source to verify weight 
and balance and to identify and resolve discrepancies. Beyond trapping weight and balance errors, 
though, additional cross-checks are required to ensure that performance parameters are correctly 
displayed in the FMS and set in the flap selector, trim control, and engine thrust selector. Existing 
technology could be applied to automate most of these final cross-checks by enabling the FMS to 
sense flap and trim positions and to compare the V-speeds that the FMS receives from the 
performance data calculations with those from its internal calculations. 

The airline industry is fortunate that performance data errors have not yet caused accidents with 
large numbers of passenger fatalities, yet our review suggests this potential exists. The FAA’s 
proposed new regulatory standards for considerations of flight crew performance and error in the 
design of aircraft equipment would, if promulgated as a final rule, address many of the relevant 
issues in a generic sense for new aircraft designs. However, older designs still in airline service 
would also have to be retrofitted with similar equipment or compensating actions taken to achieve 
the same risk controls. Our analysis, which draws upon several previous studies, presents a range of 
specific measures the industry can take to substantially reduce the potential for such accidents. All 
of these mitigations are achievable but some of them would require airlines to make significant 
investments (especially those operating aircraft with older FMS and databus communications 
systems). Cost-benefit analysis is beyond the scope of this study but the risks and potential 
consequences of performance data errors are substantial and the safety benefits of mitigating them 
are clear. Continued research and development can help by evaluating the effectiveness of the 
mitigations we suggest and by creating new approaches to mitigations— possibly at lower cost. 

The importance of these mitigations will grow as NextGen is implemented and the volume of flight 
operations increases, which will in turn increase the volume and tempo of operations required to 
prepare aircraft for flight. This greater volume will increase the number of opportunities for 
performance-data errors and the increased tempo will make it more challenging to trap errors before 
they become consequential. Also, with most information transmitted via datacom, opportunities for 

11 See AAIB, 2009b and AAIB, 201 1 incident reports; ATSB (201 1) Melbourne accident report). 
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error will increase because operators are prone to accept messages without checking content 
critically. 

Planning and research for NextGen should address this crucial aspect of flight preparation that 
occurs before aircraft begin to taxi. The mitigations described in Table 10 are all applicable to both 
current operations and NextGen operations. In particular, increasing the use of automation— with 
appropriate safeguards— to generate and transmit load and performance data will support the 
increased volume and tempo anticipated under NextGen. 
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Appendix A. Aircraft Type 


Aircraft 

Frequency 

Airbus 320 Series 

ii 

Boeing 727 

4 

Boeing 737 

35 

Boeing 747 

6 

Boeing 757 

4 

Boeing 767 

7 

Boeing 111 

6 

Boeing/Douglas DC- 10 

1 

Boeing/Douglas DC-8 

2 

Embraer Regional Jet 

2 

Boeing/Douglas MD-1 1 

1 

Boeing/Douglas MD-80 Series 

6 

Canadair Regional Jet 

6 

Turboprop (various) 

9 

Total 

100 
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